sublime text 本身不运行 php 也不内置 xdebug，调试依赖 xdebug 主动反向连接 debugger 插件；必须确保 cli 和 web 环境均启用 xdebug 3.x（xdebug.mode=debug、client_port=9003）、pathmappings 路径严格匹配、浏览器带 xdebug_session_start 参数触发，任一环节出错断点即失效。
Sublime Text 本身不运行 PHP，也不内置 Xdebug；所谓“运行”靠的是调用系统 php 命令，“调试”靠的是 Xdebug 主动反向连接 Debugger 插件——跳过任一环节或配错关键参数（path_mapping、client_port、xdebug.mode），断点就永远不亮。
php -v 能跑，但断点不触发？先确认 Xdebug 真加载了
很多人以为装完插件、改了 php.ini 就万事大吉，结果 phpinfo() 里压根没 Xdebug 模块，php -m | grep xdebug 也空着。Xdebug 是 PHP 扩展，不是 Sublime 插件，它必须在 CLI 和 Web 两套环境里都启用。
- 运行
php --ini查 CLI 实际加载的php.ini路径（常和 Apache/Nginx 的不一样） - 在该文件里加这四行（Xdebug 3.x 必须）：
zend_extension=xdebug.so（macOS/Linux）或zend_extension=php_xdebug.dll（Windows）xdebug.mode=debugxdebug.client_host=127.0.0.1xdebug.client_port=9003 - 改完重启 PHP-FPM 或 Web 服务，再执行
php -i | grep "xdebug.mode"，输出必须是debug - Windows 用户额外检查防火墙是否放行
9003端口——它不报错，只让连接静默失败
Debugger 插件监听端口和 pathMapping 怎么写才有效
Debugger 是目前唯一稳定支持 Xdebug 3.x + PHP 8.2+ 的插件，它不主动连 Xdebug，而是等 Xdebug 反向打进来。端口错一位、路径少一个斜杠，断点就变灰。
- 安装后走
Tools → Debugger → Open Launch Configurations，选 PHP 模板生成配置，别手写 JSON -
"port": 9003必须和xdebug.client_port完全一致；Xdebug 3.x 默认是9003，不是旧版的9000 -
"pathMappings"左边填 PHP 实际执行时看到的绝对路径，右边填 Sublime 当前打开的项目根目录：
Linux 容器里是/app/，就写"/app/": "${folder}/"
Windows 本地 WAMP 是C:/wamp64/www/myapp/，就写"C:/wamp64/www/myapp/": "${folder}/" - 两边路径末尾都必须带斜杠；Windows 反斜杠要换成正斜杠，否则 JSON 解析失败
- 保存后看状态栏右下角是否出现
Debugger: PHP，没出现说明配置没加载成功
浏览器怎么触发 Xdebug 连接？不是刷新页面就行
Xdebug 不会监听所有请求，它只响应带特定标识的请求。点了 “Start Debugging” 后直接刷新，等于没触发。
- 最稳方式：在浏览器地址栏手动加参数，比如
http://localhost/index.php?XDEBUG_SESSION_START=sublime.xdebug（sublime.xdebug必须和xdebug.idekey值一致） - 替代方案：装 Chrome 插件
Xdebug Helper，点虫子图标设为绿色，并在设置里填对IDE Key - 如果用 Nginx alias 或子目录部署，
url字段必须填真实可访问的 HTTP 地址，如"url": "http://localhost:8000/api/user.php"，不能填file:///或相对路径 - 确认 PHP 文件开头有
<?php，且没被缓存或重定向拦截——Xdebug 日志（xdebug.log）里出现Connecting to 127.0.0.1:9003才算真正发出了连接
路径映射错一位、端口差一个数字、xdebug.mode 写成 remote_enable，都会导致整个调试链路静默失效。没有日志、没有报错、断点只是灰色——这才是最麻烦的地方。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
