xdebug.start_with_request=yes更可靠，因它使xdebug每次请求自动连接，不依赖url参数或插件触发，兼容cli、定时任务等场景；但需配合xdebug.mode=debug且禁用所有remote_旧参数。
为什么xdebug.start_with_request=yes比trigger更可靠
远程调试连不上，八成卡在触发机制上。用XDEBUG_SESSION_START参数或浏览器插件手动触发，依赖请求带特定 query string 或 cookie，在 CLI 脚本、定时任务、API 回调等场景直接失效。设为yes后，Xdebug 每次请求自动连接，不挑入口，也不依赖客户端配合。
注意：PHP 8.0+ 的 xdebug.mode=debug 必须同时开启，且不能和旧版 xdebug.remote_enable=1 混用。配置错一条，phpinfo() 里就看不到 Xdebug 模块加载成功。
-
xdebug.mode=debug（必须） -
xdebug.start_with_request=yes（推荐） -
xdebug.client_host=host.docker.internal（Docker 容器内连宿主机 PhpStorm） -
xdebug.client_port=9003（PhpStorm 默认监听端口，别写成 9000）
PhpStorm 怎么填对「Deployment」里的 SSH 配置
很多人填完 SFTP 账号就以为部署完成了，结果断点永远灰掉——因为没告诉 PhpStorm “远程代码路径”和“本地项目路径”的映射关系。
关键不是能上传文件，而是让 PhpStorm 知道：当你在本地 /Users/me/project/index.php 打断点，它该去远程的哪个位置找同名文件校验行号。这个映射一旦错位，断点不生效，但控制台还显示“已连接”。
- 「Mappings」里必须填全路径：
/var/www/html→/Users/me/project（Linux 远程路径 ←→ 本地绝对路径） - 「Web server root URL」要写真实可访问地址，比如
https://dev.example.com，不是localhost - 勾选「Use "php -S" for local web server」毫无意义，这是本地内置服务器选项，远程调试时禁用
为什么Connection refused错误大概率是端口没通，而不是 Xdebug 没装
PhpStorm 控制台报 Connection refused，第一反应常是重装 Xdebug，其实 90% 是网络层阻断：SSH 端口转发没开、防火墙拦了 9003、或者远程 PHP 进程根本没读取到新配置。
验证顺序比重装重要：先在远程机器跑 ss -tuln | grep :9003，看有没有监听；再用 telnet 127.0.0.1 9003 从远程本地测通不通；最后才查 php --ini 加载的 ini 文件是否真包含了 Xdebug 配置。
- 如果用 SSH 隧道，确保 PhpStorm 的「Debug port」和
xdebug.client_port一致，且隧道命令用了-R 9003:localhost:9003（反向端口转发） - 云服务器（如阿里云、AWS）安全组必须放行入方向的 9003 端口，仅开放 22 不够
- Ubuntu 上
ufw status可能默认拦截，临时关掉测试：sudo ufw disable
CLI 脚本调试失败？检查php -c是否绕过了你的 xdebug.ini
Web 请求能断点，但运行 php artisan command 或 php script.php 就不进调试器——CLI 和 FPM 使用不同 php.ini，Xdebug 常只配在 php-fpm.d/ 下，而 CLI 根本没加载。
执行 php --ini，看 CLI 加载的是哪组配置；再执行 php -m | grep xdebug，确认 CLI 环境下模块是否启用。很多 Docker 镜像甚至把 CLI 和 FPM 的 php.ini 完全分开。
- 不要靠
php -d xdebug.mode=debug临时加参数，容易漏、不可靠 - 统一做法：在 CLI 的
php.ini末尾硬加入 Xdebug 配置段，或用conf.d/99-xdebug.ini方式加载 - 如果用
php -c /path/to/custom.ini启动，确保那个 custom.ini 里也复制了 Xdebug 配置
xdebug_break() 强制停住。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
