Channel pop() 不加超时会导致协程死锁，必须使用带超时的 pop(0.1)；禁止同协程先 pop 后 push 同一 Channel；关闭 Channel 必须由 sender 控制；避免传递大对象引发性能问题。
Channel pop() 不加超时就是等死
协程里调用 $ch->pop() 且没设超时，等于主动交出控制权并无限等待——调度器扫描不到其他活跃协程时，直接触发 [fatal error]: all coroutines (count: 1) are asleep - deadlock!。这不是代码逻辑错，是调度器“看丢了”你。
- 永远用带超时的
$ch->pop(0.1)，哪怕只等 10ms；返回false就该退出、重试或抛异常 - 不要依赖“对方一定会 push”，网络抖动、协程崩溃、逻辑跳过都可能导致消息永远不来
- 无缓冲
Channel尤其危险：发送和接收必须严格配对，稍有错位就卡住
禁止同一个协程里先 pop 再 push 同一个 Channel
这相当于自己给自己上锁。即使包在 go() 里也救不回来，因为协程内部顺序执行，pop() 阻塞后后续 push() 根本没机会运行。
- 典型错误：
go(function () use ($ch) { $ch->pop(); $ch->push('done'); }); - 正确做法：拆成两个协程，或改用
Atomic/Channel组合做状态同步 - 如果真要单协程通信，用
Channel(1)（带缓冲）+push()先发再pop()取，但依然要加超时
Channel 关闭时机必须由 sender 控制
receiver 主动 close($ch) 会导致所有正在 pop() 的协程立刻返回 false，但 sender 还可能继续 push() —— 触发 PHP Warning: Swoole\Coroutine\Channel::push(): channel is closed 并丢数据。
Swoole 6.1.1
下载
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
- 只允许 sender 在确认所有消息发完后调用
$ch->close() - receiver 应用
for ($i = 0; $i pop(1); }或配合select+default分支做非阻塞轮询 - 别用
while ($ch->pop())，万一 sender 没关 channel，就会无限等下去
大对象传递会拖慢 Channel 性能
通过 Channel 传 map[string]interface{} 或长数组，每次 push() 都触发深拷贝和堆分配，GC 压力飙升，协程调度延迟明显上升。
- 优先传 ID、索引或小结构体，让 receiver 自行查数据源
- 复用对象：用
new stdClass()初始化后反复赋值，避免频繁 new - 监控
memory_get_usage()和协程执行时间，发现突增就要查 Channel 传了啥
Channel 阻塞问题从来不是“会不会发生”，而是“什么时候发生”——它往往藏在低流量测试里，爆发在高并发压测时。最危险的不是报错，是静默卡住，连日志都不打。
