协程挂起或死锁会导致Swoole服务无响应、请求堆积、CPU空转但QPS骤降，需通过kill -USR1触发堆栈快照，检查suspended记录确认挂起，并结合调用链、资源持有逻辑、强制超时及最小场景复现精准定位。
协程挂起或死锁会导致Swoole服务突然无响应、请求堆积、CPU空转但QPS骤降，排查时不能依赖传统阻塞式调试思路，必须结合协程调度器状态和上下文快照定位真实挂起点。
确认是否真为协程死锁而非业务超时
执行 kill -USR1 {master_pid} 向主进程发送信号，触发协程堆栈快照输出到日志文件（默认为 swoole.log）。
检查日志末尾是否有类似 [Coroutine #123] suspended at xxx.php:45 的记录——有则确认是协程挂起；若只有大量 wait timeout 且无 suspended 字样，大概率是下游服务响应慢或未设超时，不是死锁。
这一步跳过会误判问题性质，把网络延迟当死锁处理，浪费数小时。
定位挂起协程的调用链
打开生成的协程堆栈日志，搜索关键词 suspended，找到最近一次挂起的协程编号（如 #47）。
在日志中定位该协程完整调用栈：从最顶层函数开始，逐行向下看，重点关注最后几行是否含 Swoole\Coroutine\MySQL->query、co::sleep、Channel->pop 或自定义 yield() 调用——这些是常见挂起点。
【注意：堆栈中若出现多次重复的同一函数调用（如连续3层 identical method），极可能是 Channel 满了或未配对 pop/push 导致循环等待】
检查协程资源持有与释放逻辑
方法一：静态代码扫描
查找所有使用 Channel、WaitGroup、Lock、Condition 的地方，确认每个 push 都有对应 pop，每个 add 都有匹配 done，每个 lock 都在 finally 块中 unlock。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
方法二：运行时注入检测
在协程启动前插入 Swoole\Coroutine::defer(fn() => var_dump(debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2)));，仅对疑似模块启用，观察退出路径是否覆盖全部分支。
方法三：强制超时兜底
对所有阻塞调用包裹 Co::select 或 Co::create(fn() => { /* 调用 */ }) 并设 Co::sleep(0.1) 作为心跳，避免无限等待。
复现并隔离最小死锁场景
第一步：注释掉除核心逻辑外的所有协程创建（如 HTTP 请求、定时器、子协程），保留原始挂起路径。
第二步：将疑似问题代码抽离为独立脚本，用 go(function () { /* 复现代码 */ }); 单独运行，观察是否稳定复现挂起。
第三步：在挂起点前后插入 var_dump(Co::stats());，比对 coroutine_num 和 coroutine_peak_num 是否持续增长——若峰值不断上升且不回落，说明协程未正常结束。
这一步必须做，否则无法区分是单次偶发挂起还是持续泄漏。
