swoole_get_local_cid()返回-1说明协程调度器已离线、上下文丢失，进程静默挂起；根本原因是同步i/o（如file_get_contents）、误用sleep或未协程化sdk导致死锁，需用strace或coroutine::listcoroutines()定位waiting状态协程的阻塞点。
swoole_get_local_cid() 返回 -1 就是协程调度器已离线，此时“死锁”已经发生，不是检测没开启，而是进程已静默挂起——检测本身不靠开关，靠观察和触发快照。
为什么 swoole_get_local_cid() 返回 -1 说明出问题了
这不是一个“未开启检测”的状态，而是调度器彻底失活的明确信号：当前线程已脱离任何协程上下文。它不报错、不超时、CPU 归零，kill -USR2 也无响应。这时候翻代码比等日志更有效。
- 常见诱因是误用
file_get_contents()、curl_exec()、sleep()或未协程化的 Redis/MySQL SDK - 不是所有
go()都安全——如果协程里只调Co::sleep(1)且无其他协程或 I/O 事件，调度器就会卡住 -
Swoole\Lock在协程中调用也会导致类似现象，但它本质是误用，不是死锁
怎么拿到真正有用的协程状态快照
Hyperf 默认不暴露实时协程堆栈，必须主动触发。重点不是数量，而是找出 SWOOLE_CORO_WAITING 状态且堆栈停在阻塞点的协程。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 终端执行
kill -USR1 <worker_pid></worker_pid>，Swoole 会写快照到/tmp/swoole-coroutine-*.log（注意权限，非 root 用户要确保/tmp可写） - 更可控的方式是在中间件或定时任务里插入诊断逻辑：
use Swoole\Coroutine;<br>$coros = Coroutine::listCoroutines();<br>foreach ($coros as $cid) {<br> if (Coroutine::getStatus($cid) === SWOOLE_CORO_WAITING) {<br> $trace = Coroutine::getBackTrace($cid, 0, 20); // 第二个参数必须是 0，才能看到最深调用帧<br> // 检查 $trace 最后几行是否含 stream_select / socket_read / curl_exec 等 }<br>} -
Coroutine::listCoroutines()返回的是整数数组，别当成对象链式调用
strace 是第一道排查防线
当进程“假死”但无日志时，strace 比看 PHP 日志更快定位系统层阻塞点。
- 运行
strace -p <pid> -e trace=epoll_wait,read,write,futex</pid> - 如果长期卡在
epoll_wait且无后续read/write，说明调度器没收到任何 I/O 事件唤醒 - 若卡在
futex，可能是Swoole\Lock或 PCNTL 导致的进程级阻塞，和协程无关 - 配合
php ./vendor/bin/swoole-tracker status查coroutine_num是否长期为 0 或 1
真正难处理的不是“怎么开启检测”，而是协程死锁本身没有错误抛出、不占 CPU、不写日志——它安静得像没发生。所以日常开发中，所有 go() 必须配 I/O 操作或超时控制，所有第三方 SDK 要确认是否声明支持 Swoole 协程，尤其是 connect() 和 __construct() 里有没有 stream_socket_client 这类同步调用。
