channel是协程间通信的调度原语，非存储容器；其核心是一端写、另一端读，不支持自读、遍历、长度判断轮询，关闭后仅终止操作而非清空数据，适用同进程协程协作场景。
Channel 是协程间通信的“管道”，不是存储容器
很多人一看到 push 和 pop 就下意识当成队列用，结果在协程退出后还去 pop，或者反复 push 却没消费者——这本质上是混淆了「通道」和「队列」的设计意图。
Channel 的核心语义是「一端写、另一端读」：数据从生产者协程写入后，**必须由另一个（或多个）消费者协程主动 pop 才能取出**；它不提供「自己写自己读」「遍历内容」「查看长度后决定是否操作」这类队列式能力。底层没有持久化、不支持随机访问、也不允许单协程闭环使用。
- 写入方调用
push后，若无消费者等待，数据暂存缓冲区；但一旦缓冲区满，协程自动yield，直到有消费者pop腾出空间 - 读取方调用
pop时，若缓冲区为空，协程直接挂起，直到有生产者push新数据 -
isEmpty()和length()这类方法仅作状态快照，**不能用于条件轮询**（比如while (!$chan->isEmpty()) { $chan->pop(); }极易漏数据或死锁）
队列（如 SplQueue / Redis Queue）是独立数据结构，Channel 不是
常见误区：把 Swoole\Coroutine\Channel 当成内存版 SplQueue 或 Laravel 的 database 队列来用。这是危险的。
真正队列（如 SplQueue）是纯数据容器：你可以 enqueue、dequeue、count()、rewind()，甚至序列化保存。而 Channel 是调度原语——它的存在意义是触发协程切换，不是存数据。
-
SplQueue可跨函数、跨作用域复用，Channel 实例一旦所属协程结束，未消费数据即丢失（无 GC 保证） - Redis 队列可被多进程、多机器消费，Channel **严格限于同一 Swoole 进程内的协程之间**，跨 worker 进程完全不可见
- 你无法对 Channel 做
serialize()或写入文件，它不实现任何 PHP 序列化接口
Channel 关闭行为与队列清空完全不同
调用 $chan->close() 不等于「清空队列」，而是向所有阻塞中的 push/pop 协程广播「通道已终止」信号。
Swoole 6.1.1 是一个专为 PHP 设计的高性能事件驱动并发网络引擎。作为稳定版，它修复了编译时对 zlib 依赖的缺失及 curl 模块的内存安全风险。该版本支持协程、多线程与多进程架构，内置 TCP/HTTP/WebSocket 服务器，能够显著提升 PHP 在微服务、实时通信等场景下的执行效率与并发能力。
此时：pop() 返回 false，push() 也返回 false（不再阻塞）。这个机制专为「优雅退出」设计，比如用 null 作哨兵通知消费者结束，比手动计数更可靠。
- 未关闭时，空
pop会永久挂起协程（除非设超时）；关闭后立即返回false - 关闭后不能再
push，但缓冲区中已有数据仍可被pop直到取完 - 不要依赖
close()来「清理残留数据」——它不清理，只终止后续操作
什么时候该用 Channel，什么时候该用队列
选型关键看「通信意图」而非「数据暂存需求」。
用 Channel：协程之间需要同步协作，比如一个协程拉日志、另一个实时分析；或连接池中，工作协程 pop 获取空闲连接，用完再 push 回池——这里重点是「交接控制权」，不是存日志或连字符。
用队列：需要解耦生产/消费时间（如用户下单后发短信，允许延迟几秒）、需持久化防丢（如支付回调重试）、或多进程协同（如 Laravel Horizon 处理 HTTP 请求队列）。
- 高频、低延迟、同进程内协程协作 →
Swoole\Coroutine\Channel - 需失败重试、跨服务、消息保序、审计追踪 → Redis / RabbitMQ / 数据库队列
- 只是临时缓存一批数据供本协程后续处理 → 直接用数组或
SplQueue，别硬套 Channel
最常被忽略的一点：Channel 的容量设置（构造时传的整数）不是「最大积压量」，而是「协程切换触发点」。设太小会导致频繁 yield，设太大可能掩盖消费者性能瓶颈——这个值要结合实际吞吐和协程数量压测调整，不能拍脑袋填 1024。
