swoole协程死锁表现为协程永久挂起、连接无响应等“假死”现象，主因是误用同步原语：如未hook的sleep()卡住mutex锁、容量为0的channel未配对push/pop、跨协程共享未隔离资源、http客户端未设超时等。
在 Swoole 协程环境下，死锁不会像传统多线程那样触发系统级阻塞等待，但会表现为协程永久挂起、连接无响应、Channel 读写卡住、资源无法释放等“假死”现象。这类问题往往难以复现又极难定位，核心原因在于协程调度模型下对同步原语的误用。
协程中滥用 synchronized 或 mutex->lock() 导致调度停滞
Swoole 没有 Java 那样的内置可重入锁机制，Swoole\Coroutine\Lock（包括 Mutex、Channel）是协程安全的，但一旦在 lock 后未 unlock，或在 lock 期间调用了未 hook 的阻塞函数（如原生 sleep()、file_get_contents()），当前协程将无法让出控制权，整个协程栈被冻结。
- 错误写法：
$mutex->lock(); sleep(1); $mutex->unlock();——sleep()未被协程化，协程卡死 - 正确做法：必须启用完整 Hook：
Swoole\Runtime::enableCoroutine(SWOOLE_HOOK_ALL);，并改用co::sleep(1) - 更安全替代：优先用
Swoole\Coroutine\Channel做生产者-消费者解耦，避免显式加锁
Channel 容量为 0 且未配对使用 push/pop
Swoole\Coroutine\Channel 默认容量为 0（同步 Channel），push() 和 pop() 必须严格成对出现，否则一个协程卡在 push、另一个卡在 pop，形成双向等待。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 典型陷阱：
$ch = new Channel(); go(function () use ($ch) { $ch->push('data'); }); go(function () use ($ch) { $ch->pop(); });—— 两个协程启动时机不可控，极易卡住 - 修复方式：显式指定容量，如
new Channel(1)；或确保 push/pop 在同一线性流程中（如先 pop 再 push） - 调试技巧：用
$ch->stats()查看consumer_num和producer_num，非零即说明有协程阻塞
嵌套 go() 中跨协程共享资源未隔离
协程间不共享局部变量，但若通过全局变量、静态属性、类成员或闭包引用传递了同一对象（如 PDO 实例、Redis 连接），而该对象内部状态未做协程隔离，就可能因并发修改引发隐式竞争和调度异常。
- 高危代码：
static $db; if (!$db) $db = new PDO(...); return $db->query(...);—— 多个协程共用一个未做连接池封装的 PDO - 根本解法：禁用静态单例，改用连接池（
Swoole\Coroutine\MySQL\Pool）或每次新建轻量客户端 - 注意：即使用了连接池，也需确保
get()/put()成对，漏掉put()会导致连接泄漏+后续协程无限等待
HTTP 客户端未设超时 + 大模型流式响应未分块消费
对接 LLM API 时，Swoole\Coroutine\Http\Client 若未设置 timeout 或 response_chunk_size，配合流式 Transfer-Encoding: chunked 响应，极易在 recv() 时无限等待首 chunk，导致整个协程挂起。
- 错误配置：
$cli->set(['timeout' => 0]);或完全不 set - 必须显式设置：
$cli->set(['timeout' => 60, 'response_chunk_size' => 8192]); - 流式消费要主动循环：
while ($body = $cli->recv()) { ... }，不能只调一次recv()就结束 - 补充防护：在
go()外层包一层co::sleep()超时兜底，或用Channel配合select()做超时控制
真正棘手的死锁往往不报错、不抛异常，只表现为某几个连接永远没响应。排查时优先检查 Channel->stats()、coroutine::list() 输出的协程状态，再结合 strace -p $(pgrep php) 看是否卡在 epoll_wait 或 futex 上——那基本就是调度器被某个未释放的锁或未消费的 Channel 给锁死了。
