协程中调用 swoole\coroutine\system::sleep() 卡死，是因为在无协程调度器的进程里执行所致；典型场景是父进程禁用协程后子进程仅启一个无限 sleep 的协程，导致调度器失活、进程挂起。
协程里用 Swoole\Coroutine\System::sleep() 为啥会卡死？
不是 sleep 本身有问题，是它在“没协程调度器的进程里”被调用了。典型场景：父进程禁用了协程（swoole_async_set(['enable_coroutine' => false])），却在子进程中启了一个协程、只干一件事——无限 sleep(1)。这时 Swoole 认为“所有协程都在睡，没人可调度”，整个进程就挂起不动了，表现就是死锁。
- 这种死锁不报错、不超时、CPU 占用极低，容易误判成“空闲”
- 定时器回调（如
Swoole\Timer::after()）触发子进程启动后，若子进程内没有其他协程或 I/O 事件唤醒调度器，就会立即卡住 -
sleep()是协程让出控制权的操作，但前提是得有调度器在背后轮转——没调度器，它就真“睡过去”了
怎么快速定位是不是协程调度导致的卡死？
用 swoole_tracker 工具秒级抓现场，比翻日志快得多：
- 启动服务前加环境变量：
export SWOOLE_TRACKER=1 - 请求卡住时执行：
php ./vendor/bin/swoole-tracker status - 关键看输出里的
coroutine_num和coroutine_peak：如果前者长期为 0 或 1，且没活跃 I/O（如tcp_connections不增），大概率是调度器失活 - 再配合
strace -p [pid] -e trace=futex,clone,wait4，能看到进程是否卡在 futex 等待上（协程调度底层依赖 futex）
子进程协程死锁的两种修复路径
别硬扛，根据实际架构选：
✅ 推荐：在父进程启用协程，让调度器全程在线
swoole_async_set(['enable_coroutine' => true])放在Process创建前，确保定时器回调、子进程创建、协程启动全在同一个调度上下文里⚠️ 慎用：在子进程禁用协程，改用同步 sleep
swoole_async_set(['enable_coroutine' => false])放在子进程回调开头，然后直接用sleep(1)（非协程版）。但这等于放弃并发能力，仅适合调试或极简守护逻辑❌ 别试：只加
go()不检查调度环境——协程跑不起来，和没写一样
除了 sleep，还有哪些操作会悄悄触发类似死锁？
本质都是“单协程 + 无唤醒事件”，常见陷阱：
-
while (true) { go(fn() => { /<em> 只 sleep，无其他 I/O </em>/ }); }：协程池不断创建新协程，但每个都只睡，最终耗尽内存或调度器过载 - 使用
curl_exec()或未设超时的Swoole\Client->connect()：协程阻塞在网络等待上，又没设置timeout，等同于无限 sleep - 在协程中调用
session_start()：PHP 默认文件锁机制会阻塞整个协程，且不释放锁直到脚本结束，多个请求串行化卡死 - 忘记
yield或co::sleep()替代usleep()：后者是系统级阻塞，会拖垮整个进程
真正难排查的，往往是那个没打日志、没设超时、也没加 try/catch 的协程分支——它不报错，只是永远不回来。
