Channel初始化必须指定容量，否则pop会永久阻塞；默认无界通道在空时仍挂起，无人push则协程卡死，正确做法是显式传入正整数容量如1或10。
Channel 初始化必须指定容量，否则 pop 会永久阻塞
很多人写 $channel = new \Swoole\Coroutine\Channel() 后直接 pop()，结果协程卡死。这是因为未设容量时，默认是「无界通道」，但 pop() 在空时仍会挂起——而没人 push()，它就永远等下去。
正确做法是显式传入整数容量：
-
new \Swoole\Coroutine\Channel(1)：单元素缓冲，适合“一生产一消费”场景（如返回单个查询结果） -
new \Swoole\Coroutine\Channel(10)：预分配 10 个槽位，适合批量数据中转 - 传
0是非法的，会抛InvalidArgumentException
注意：Hyperf 7.1 的 Channel 是对 Swoole\Coroutine\Channel 的封装，行为一致，不额外做容错。
push 和 pop 不是同步调用，要靠协程调度自动唤醒
push() 和 pop() 都是协程友好的阻塞操作，但它们的阻塞逻辑不同：
-
push($data)：若通道已满，当前协程 yield，等待有消费者pop()后被唤醒；成功后立即返回，不等待其他协程 -
pop()：若通道为空，当前协程 yield，等待有生产者push()后被唤醒；返回值就是那个push进来的数据
常见错误是以为 pop() 会“轮询等待”，其实它只等一次：一旦被唤醒并取到数据，就继续执行；如果想带超时控制，得用 pop($timeout)，比如 pop(0.1) 表示最多等 100ms，超时返回 false。
多生产者/多消费者下，pop 顺序不保证 FIFO，但 push 顺序严格保留
当多个协程同时 push()，数据进入通道的顺序就是调用顺序；但多个协程同时 pop() 时，谁先被唤醒、谁拿到哪条数据，由 Swoole 调度器决定，不是严格的先进先出。
Approve new channels, and connections to openclaw ui and terminal
下载
Web仪表盘，用于审批OpenClaw设备与通道配对、管理连接，并可从浏览器访问实时终端。
这意味着：
- 不能依赖
pop()返回顺序来实现业务逻辑（比如认为第 1 个pop()一定拿到第 1 个push()的值） - 若需顺序保障，应在生产端加序号字段，或改用单消费者 + 显式队列管理
- 高并发下，
pop()唤醒延迟通常在微秒级，但不承诺实时性
别在非协程环境调用 Channel 方法，会直接报错
\Swoole\Coroutine\Channel 只能在协程内创建和使用。如果在控制器方法里直接 new 并 push/pop，且该方法没被 co() 或 Hyperf 的协程中间件包裹，就会触发 Fatal error: Uncaught Swoole\Exception: must be called in the coroutine。
验证方式很简单：
- 用
Hyperf\Utils\Coroutine::inCoroutine()判断当前是否在协程中 - Hyperf 默认 HTTP 请求已运行在协程上下文，但 CLI 命令、定时任务、或手动
go()外的代码不一定 - 在
Command类里使用 Channel，必须包一层co(function () { ... })
最易忽略的一点：Channel 对象本身不能跨协程传递引用（比如塞进全局变量），它只在创建它的协程栈内有效；跨协程通信只能靠 push/pop 数据，而不是传对象。
