Channel必须在协程环境中创建和使用，否则抛出Fatal error；容量设为0导致同步阻塞易死锁，设为1易卡住生产者；pop()不加超时会永久阻塞；Channel仅限单进程内协程通信，跨进程需用Redis或RabbitMQ。
Channel 必须在协程环境里创建和使用
直接 new Swoole\Coroutine\Channel 但没在协程上下文中运行，会报错 Fatal error: Uncaught Swoole\Exception: must be called in the coroutine。这不是配置问题，是底层强制校验——Swoole 的 Channel 完全依赖协程调度器管理读写挂起，非协程中连对象初始化都失败。
常见错误场景：
- 在 Worker 进程启动回调（如
onWorkerStart）里直接 new Channel，却没用go或Co::create包裹 - 在普通 PHP CLI 脚本里调用，忘了加
Co\run()或Swoole\Coroutine\run()
正确做法是：所有 Channel 实例必须诞生于已启动的协程内。例如：
Co\run(function () {
$chan = new Swoole\Coroutine\Channel(1024);
go(function () use ($chan) {
$chan->push(['id' => 1]);
});
go(function () use ($chan) {
var_dump($chan->pop());
});
});
容量设置不当会导致协程意外挂起
Channel 构造时传入的 $capacity 不是“建议值”，而是硬性缓冲区上限。设为 1 时，第二个 push 就会阻塞，直到有协程 pop 出一个数据腾出空位——这容易让生产者协程卡住，尤其当消费者处理慢或未及时启动时。
关键点：
- 容量为
0表示无缓冲，push和pop必须严格配对，类似 Go 的无缓冲 channel，极易死锁 - 容量过小（如
1）会让多个生产者互相等待，输出时间戳错乱，调试时很难定位 - 容量过大（如
100000）虽不阻塞，但会占用更多内存，且掩盖了消费者吞吐不足的问题
建议按典型并发量 × 单次处理耗时预估：比如每秒 100 条消息、平均处理 50ms，缓冲 5~10 条足矣，设 16 或 32 更稳妥。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
pop() 不带超时参数可能永久阻塞
$chan->pop() 默认无限等待，若生产者还没 push、或已 close、或所有数据已被取完，消费者协程就再也醒不过来。线上服务里这种“静默卡死”比报错更难排查。
必须显式加超时，例如：
-
$chan->pop(1.5)：最多等 1.5 秒，超时返回false，可通过$chan->errCode === SWOOLE_CHANNEL_TIMEOUT判断 -
$chan->pop(0)：非阻塞模式，立即返回，没数据就返回false
注意：pop() 返回 false 不一定代表超时，也可能是 Channel 已关闭，得结合 errCode 判断。别只靠 if (!$data) 就 break，漏掉关闭状态会跳过清理逻辑。
跨进程通信不能用 Channel
Swoole\Coroutine\Channel 完全基于当前进程的内存，Worker A 里的 $chan 和 Worker B 里的同名变量毫无关系。试图在多 Worker 场景下靠它传订单、发通知，数据必然丢失。
替代方案要按场景选：
- 单 Worker 内多协程协作（如请求解析 + 参数校验 + 日志记录）→ 用
Channel - 同机多 Worker 共享队列（如订单分发给不同 Worker 处理）→ 改用
Redis的lPush/brPop - 分布式或多机部署，要求持久化、ACK、重试 → 上
RabbitMQ或Kafka
最容易忽略的是：Swoole HTTP Server 默认开启多 Worker，哪怕你只写了一个 go，它也可能被调度到任意 Worker 进程里执行——此时 Channel 就失效了。确认是否真需要跨进程，比调通代码更重要。
