Workerman进程启动后Xdebug不生效，需确认CLI模式php.ini已启用Xdebug、配置xdebug.mode=debug等参数，并在Worker::runAll()前调用xdebug_break()手动触发调试连接。
Workerman进程启动后Xdebug不生效？检查CLI模式配置
Workerman是常驻内存的命令行程序，Xdebug默认可能只对Web SAPI生效。必须确认当前PHP CLI使用的php.ini已启用Xdebug，且zend_extension路径正确指向xdebug.so（Linux/macOS）或php_xdebug.dll（Windows）。
运行php -m | grep xdebug或php -i | grep "xdebug.mode"验证是否加载成功。常见错误是Web服务器（如Nginx+PHP-FPM）和CLI共用同一份php.ini但Xdebug被条件注释，或CLI实际读取的是/etc/php/8.2/cli/php.ini而非/etc/php/8.2/apache2/php.ini。
-
xdebug.mode = debug（非develop或off） -
xdebug.start_with_request = trigger（避免自动开启导致性能损耗） -
xdebug.client_host = 127.0.0.1（确保与IDE监听地址一致） -
xdebug.client_port = 9003（PHP 8.0+默认端口，不是旧版9000）
在Worker::runAll()前手动触发Xdebug连接
Workerman主进程启动后会fork子进程，而Xdebug连接通常在进程初始化阶段建立。若等待IDE自动监听，子进程可能因超时错过握手。最可靠方式是在代码入口处显式调用xdebug_break()，强制中断并等待调试器连接。
示例位置（放在Worker::runAll()之前）：
if (function_exists('xdebug_break')) {
xdebug_break(); // 此处会暂停，IDE需已启动监听
}
Worker::runAll();
注意：此方法仅适用于单进程调试（如开发环境启一个Worker）。若用Worker::$processCount = 4，每个子进程都会停住，需在IDE中逐个恢复，容易混乱。
VS Code中launch.json配置要点
VS Code需用php.debug扩展，并配置launch.json为launch类型，而非attach——因为Workerman是主动启动的CLI程序，不是先运行再附加。
Xdebug 3.4.1 是一款功能强大的 PHP 调试扩展工具，于 2025 年 1 月 6 日正式发布。作为 Xdebug 3.4 系列的首个修复版本，3.4.1 版在继承上一版本强大功能的同时，重点解决了稳定性问题。该版本不仅修复了访问超全局变量时可能引发的程序崩溃现象，还增强了对 Windows 平台 PIE 构建机制的支持，为广大 PHP 开发者提供了更加稳定的调试环境。这一版本适合所有
"type": "php""request": "launch""name": "Debug Workerman"-
"program": "${workspaceFolder}/start.php"（指向你的Workerman启动脚本） -
"console": "integratedTerminal"（方便看到Workerman日志输出） -
"port": 9003（必须与xdebug.client_port一致）
如果使用attach模式，需额外在命令行加XDEBUG_CONFIG="idekey=VSCODE"环境变量，并确保IDE已开启监听——但不如launch稳定，尤其遇到多进程时易丢失断点。
断点失效或无法进入回调函数？检查Worker的异步执行路径
Workerman大量使用onMessage、onConnect等回调，这些函数由事件循环在子线程/子进程中调用，Xdebug默认不会跨进程继承调试上下文。即使主进程连上了，子进程的回调也可能不触发断点。
解决思路只有两个：
- 把关键逻辑抽离成独立函数，在
xdebug_break()后手动调用，确保在当前调试进程内执行 - 改用
var_dump()+debug_backtrace()临时定位，比强求断点更实际
另外，Worker::reload()会重启子进程，Xdebug连接会被重置，每次热更后需重新触发xdebug_break()或重启调试会话。
Workerman本质是无HTTP请求生命周期的长连接模型，Xdebug的“一次请求一次会话”设计天然不匹配。真要深度调试，优先考虑日志+断点组合，而不是指望全程单步跟进所有回调。
