先说配置的几个逻辑:
1. vscode是要通过php debug插件启动9003监听端口
2. docker的宝塔启动xdebug后,是将运行信息推送到vscode宿主的9003端口;这里有个难点,docker内的宝塔和vscode不在一个本地,是个网络环境,因此需要ip+端口访问
3. vscode根据推过来的9003,匹配到对应文件的断点信息,完成断点调试;这里也有个难点,就是docker中的文件地址和vscode的地址不一致,相比纯本地环境,两边的文件路径不一致,因此需要映射
先下配置的步骤:
1. vscode中安装php debug,然后设置配置。这里有个关键是pathMapping,因为在docker中的文件目录是/www/wwwroot/sources/gitee.com,而本地的文件是:/Users/chensm/Desktop/sources/gitee.com
2. 在docker的宝塔php.ini中的配置(首先需要先安装xdebug),需要调整zend_extension本地的对应目录。
另外,这个是xdeubg3的配置。xdebug2 的配置稍许有些差别,网上自己找了
[Xdebug] zend_extension=/www/server/php/74/lib/php/extensions/no-debug-non-zts-20190902/xdebug.so xdebug.mode = debug xdebug.start_with_request = yes xdebug.client_host=docker.for.mac.localhost xdebug.client_port=9003 xdebug.idekey=VSCODE xdebug.log=/tmp/xdebug.log的
3. 正常情况下载vscode设置断点,运行就有效果了。
常见问题
大家肯定大概率是碰到的问题是断点不起作用,那到底是vscode配置问题还是docker中的宝塔的问题?
知道背后逻辑后,其实并不难,就是要找到问题。我咧了几个排查的方式
1. 排查vscode的debug 监听是否正常启动了
在本地运行 如下命令,看是否本地能连上监听端口,连上就是是好的
curl 127.0.0.1:9003
2. 排查docker中的宝塔xdebug是否正常
phpinfo()中看到xdebug是否有信息,有就是正常的;
在docker中 查看是否有日志,有就是正常的
tail -f /tmp/xdebug.log
3. 排查docker到本地网络是否通畅
curl docker.for.mac.localhost:9003
4. 检查docker中和vscode的文件隐射是否正确
在docker中运行
tail -f /tmp/xdebug.log
以如下日志为例:
[33773] [Step Debug] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="breakpoint_remove" transaction_id="24"><breakpoint type="line" resolved="resolved"
filename="file:///www/wwwroot/sources/gitee.com/chenshiming0802src/fastadmin_addons_csmitsm/addons/csmitsm/controller/Index.php"
lineno="23" state="enabled" hit_count="1" hit_value="0" id="337730006"></breakpoint></response>
可以清楚的看到filename是vscode设置的这个文件的断点,但是在docked中这个文件路径是:
/www/wwwroot/sources/gitee.com/chenshiming0802src/fastadmin_addons_csmitsm/addons/csmitsm/controller/Index.php
因此在vscode的debug中配置隐射是
"/www/wwwroot/sources/gitee.com":"/Users/chensm/Desktop/sources/gitee.com"
本文既是对自己的知识的留痕,希望也对大家有所帮助