死锁是协程调度器误判所有协程休眠而触发的致命错误，主因包括单协程无限sleep、channel环形等待、hook缺失导致隐式阻塞、静态变量引发伪死锁；需用超时、协程客户端、channel/atomic替代共享变量。
死锁不是代码写错了，而是协程调度器“看丢了”正在运行的协程——只要它判定当前所有协程都处于 sleep 或 pop 等待状态，且无任何协程能被唤醒，就会报 [fatal error]: all coroutines (count: 1) are asleep - deadlock!。
为什么 Swoole\Coroutine\System::sleep() 会触发死锁
根本原因不是 sleep() 本身阻塞，而是它让协程进入 SUSPENDED 状态后，调度器找不到其他可运行协程来接管控制权。尤其在单协程、无 I/O 事件、主进程禁用协程的组合下极易发生。
- 主进程调用
swoole_async_set(['enable_coroutine' => false])后，定时器回调中启动子进程，子进程内只起一个协程并无限sleep(1)—— 调度器扫描不到活跃协程，直接判为死锁 -
sleep()不是协程安全的“等待”，它是显式挂起点；若周围没有其他协程做保底（比如监听信号、轮询 channel、处理网络事件），就等于主动交出全部控制权 - 注意：PHP 原生
sleep()在未启用SWOOLE_HOOK_ALL时会直接阻塞整个 Worker 进程，和协程死锁是两回事，但现象类似（请求卡死）
Channel 嵌套使用导致环形等待
多个协程通过 Channel 相互等待，形成闭环依赖，调度器无法打破僵局。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 典型场景：父协程先
$ch->pop()，等子协程$ch->push()；但子协程自己也在等另一个Channel，而那个Channel又被父协程持有 - 绝对禁止在同一个协程里对同一
Channel先pop()再push()—— 这等于自己给自己上锁，go()包一层也救不回来 - 生产环境必须加超时：
$ch->pop(0.1)，哪怕 10ms，避免无限等待；pop()返回false时需主动退出或重试逻辑
协程 Hook 缺失导致隐式阻塞
协程调度器只接管了被 hook 的系统调用。没被 hook 的操作（如 file_get_contents()、PDO 构造、原生 sleep()）会同步阻塞整个 Worker，使所有协程“假死”。
- 验证是否生效：在协程里执行
sleep(1)，同时发起另一个 HTTP 请求，看后者是否被卡住 —— 卡住说明SWOOLE_HOOK_ALL没启用或启用位置太晚（必须在go()之前） - 推荐分层启用：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_STDIO | SWOOLE_HOOK_CURL | SWOOLE_HOOK_FILE)，比全量更可控 - 数据库连接务必用协程版客户端（如
Swoole\Coroutine\MySQL），PDO 默认不协程化，构造即阻塞
全局变量与静态变量引发的“伪死锁”
这不是调度器层面的死锁，但会导致协程行为异常，容易被误判为死锁。
- 所有协程共享
static变量、global、$_SERVER等 —— 若某个协程修改了static $flag = true，后续协程可能因条件判断失败而跳过关键逻辑，表现为“卡住” - 协程栈独立，但变量生命周期不随协程结束自动清理；未
unset()的大数组或对象引用会持续占内存，Worker 进程变慢甚至 OOM，看起来像响应延迟或死锁 - 解决方式不是加锁，而是避免跨协程共享状态；必须共享时，用
Channel或Atomic显式通信，而非读写同一变量
真正难调试的从来不是报错信息里的 deadlock，而是那些没报错却永远不返回的协程——它们往往卡在没设超时的 Channel、没被 hook 的文件读取、或者被静态变量悄悄改写了执行路径。盯住 coroutine_stats() 输出的协程数和状态，比猜逻辑更可靠。
