websocket请求无法被xdebug断点捕获，因xdebug默认仅介入http生命周期（如php-fpm处理的握手阶段），而后续onmessage逻辑由独立长进程（如swoole）处理，需手动在回调开头加xdebug_break()并确保cli模式下正确加载xdebug扩展。
WebSocket请求无法被Xdebug断点捕获？检查xdebug.mode和触发方式
WebSocket连接建立后，后续的onmessage处理逻辑默认不会被Xdebug自动介入——因为Xdebug默认只对HTTP生命周期（如index.php入口）生效，而WebSocket长连接通常由独立进程（如Swoole、Workerman）或PHP-FPM子进程持续处理，不走标准请求周期。
解决办法不是“让Xdebug监听所有PHP执行”，而是精准控制调试入口：
-
xdebug.mode=develop,debug必须启用，但xdebug.start_with_request=trigger更安全：仅当请求头带XDEBUG_SESSION_START=PHPSTORM时才启动调试，避免污染长连接上下文 - 若用Swoole，需在WebSocket
onMessage回调开头手动加xdebug_break()，并确保该进程已加载Xdebug扩展（CLI模式下需单独配置php.ini） - 不要依赖
session_start()触发Xdebug——WebSocket连接通常不携带Cookie，且Session锁会阻塞并发消息处理
Ajax并发请求被阻塞？优先关掉Xdebug再排查SESSION锁
当你发现多个$.get()或$.post()在Chrome Network里排队等待，响应时间逐个拉长，大概率不是代码问题，而是Xdebug在后台把PHP-FPM进程串行化了。
原因很直接：xdebug.mode=debug开启时，Xdebug会强制FPM使用单线程模型同步调试状态，哪怕你没打任何断点。这不是bug，是设计使然。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 开发中真要调试Ajax并发，先注释掉
xdebug.mode，或临时设为develop,profile（去掉debug） -
session_write_close()必须在ob_end_flush()之后调用，否则输出缓冲区未清空会导致Session文件锁延迟释放 - Redis作为Session存储时，
session_write_close()基本无效——改用session_commit()或直接禁用Session（session_abort()）更可靠
为什么WebSocket握手成功但后续消息不进Xdebug？看清楚是哪个PHP进程在跑
WebSocket握手（HTTP Upgrade）阶段能被Xdebug捕获，是因为它走的是标准FPM/CGI流程；但升级后的数据帧收发，往往由另一个长期运行的PHP进程处理——比如用php socket_create()手写的服务器，或Swoole Worker子进程。
这类进程默认不读取Web服务器的php.ini，而是读取CLI配置。所以即使你在/etc/php/8.3/apache2/php.ini里配好了Xdebug，CLI进程也看不到。
- 运行
php --ini确认CLI实际加载的配置路径，把Xdebug配置复制过去 - CLI模式下
xdebug.start_with_request=yes无效，必须用XDEBUG_CONFIG="idekey=PHPSTORM"环境变量启动 - 用
ps aux | grep php查进程，区分出是apache2还是php主进程——前者走Web配置，后者走CLI配置
调试Ajax时var_dump()输出乱码或截断？别忽略output_buffering和xdebug.var_display_max_depth
前端收到的Ajax响应里出现、[...]或JSON解析失败，常因Xdebug的变量输出干扰了原始响应流。
-
output_buffering=Off在CLI和FPM配置里都要检查，否则var_dump()会卡在缓冲区，导致echo json_encode(...)被截断 -
xdebug.var_display_max_depth=5太浅，嵌套数组/对象会被省略；设为10更稳妥，但别无脑调高——深度过大拖慢响应 - 生产环境绝对禁用
xdebug.output_dir，日志写满磁盘比慢响应更致命
php.ini，而Xdebug一旦加载，就接管整个Zend引擎的执行钩子。
