VSCode中Xdebug连不上99%是php.ini配置错误：需同时设置xdebug.mode=debug、xdebug.client_host=127.0.0.1、xdebug.client_port=9003，并重启Web服务器；pathMappings须匹配PHP运行时路径与本地路径；HTTP调试需启用xdebug.start_with_request=yes并配合浏览器插件。
VSCode里xdebug连不上，99%是php.ini里这三行没配对
不是VSCode的问题，也不是Xdebug版本不兼容，而是PHP运行时根本没加载Xdebug或没暴露调试端口。重点看三处是否同时生效：
-
xdebug.mode=debug（Xdebug 3+ 必须显式启用，旧版xdebug.remote_enable=1已失效） -
xdebug.client_host=127.0.0.1（别写localhost，某些系统DNS解析慢或失败） -
xdebug.client_port=9003（Xdebug 3默认端口是9003，不是旧版的9000；VSCode的launch.json里port必须一致）
改完php.ini后，务必重启Web服务器（如Apache/Nginx）或PHP-FPM进程，仅重启VSCode无效。用php -v和php --ini确认当前生效的配置文件路径，再用php -m | grep xdebug验证模块是否加载。
launch.json里pathMappings填错，断点永远灰掉
VSCode找不到PHP文件对应关系，断点就只是个装饰。关键不是“本地路径怎么写”，而是“PHP运行时看到的路径”和“你本地编辑器打开的路径”之间怎么映射。
- 如果PHP跑在Docker里，
"pathMappings": { "/var/www/html/": "${workspaceFolder}/" }—— 左边是容器内绝对路径，右边是你本地项目根目录 - 如果用MAMP/XAMPP本地运行，且项目放在
/Applications/MAMP/htdocs/myapp，那左边应填/Applications/MAMP/htdocs/myapp/，右边用${workspaceFolder} - 路径末尾统一加
/，否则映射可能部分失效；Windows用户注意斜杠方向，VSCode里一律用/，不用\
验证方法：启动调试后，在VSCode调试控制台输入$_SERVER['SCRIPT_FILENAME']，看输出的路径，再对照pathMappings左边是否能完全匹配它。
立即学习“PHP免费学习笔记（深入）”；
HTTP请求进不来调试，start_with_request=yes没开
Xdebug不会自动监听每个HTTP请求，得明确告诉它“这次也要介入”。只靠VSCode点“开始调试”只能触发CLI脚本，网页访问不会自动连接。
- 必须在
php.ini里加xdebug.start_with_request=yes（Xdebug 3.1+）或xdebug.remote_autostart=1（旧版） - 浏览器要装Xdebug Helper插件（Chrome/Firefox都有），并点击图标切换为“Debug”模式，它会在请求头里带
XDEBUG_SESSION_START=PHPSTORM（值不重要，只要存在） - 如果用cURL或Postman测试，手动加Header：
XDEBUG_SESSION_START: 1
没开这个，就算xdebug.mode=debug开着，也只响应CLI调用，网页请求直接绕过Xdebug。
断点进了但$_GET、$_POST为空，其实是请求被重写了
常见于Laravel、WordPress或用了URL重写的项目。Web服务器把原始URL转成了index.php?/path/to/page这类形式，但Xdebug捕获的是重写后的入口脚本，变量早被框架清空或未初始化。
- 先确认是否真为空：在断点处执行
print_r($_SERVER['REQUEST_URI'])，看是不是被Nginx/Apache重写过了 - 如果是Nginx，检查
try_files规则，确保$args被正确传递到index.php - 临时绕过：直接访问
http://localhost/index.php?name=test，看$_GET是否正常，能排除是重写导致的变量丢失
这不是Xdebug的锅，但容易误判成配置问题。真正要调的，是Web服务器的重写逻辑和框架的请求生命周期入口点。
