Swoole 4 的 Channel 读写需显式设超时并捕获关闭异常，否则协程可能永久挂起；pop/push 必须传 $timeout 参数，关闭后操作抛 Swoole\Error，应结合 isClosed() 检查、try-catch 及 defer close 确保安全。
Swoole 4 的 Swoole\Channel 是协程间安全通信的核心工具，但它的读写行为天然具备阻塞特性——若无数据可读或缓冲区已满，pop() 和 push() 会挂起当前协程。因此，“超时”和“关闭异常”不是默认行为，必须显式控制，否则容易导致协程永久挂起或 panic。
通道读写必须带超时参数，不能依赖外部等待
Channel 的 pop() 和 push() 方法均支持可选的 $timeout 参数（单位：秒，支持浮点数）。不传该参数即为无限等待，一旦另一端未及时 push 或 pop，协程将卡死。
-
$chan->pop(2.5)：最多等 2.5 秒，超时返回false，协程继续执行 -
$chan->push($data, 1)：最多等 1 秒等待缓冲区腾出空间，失败返回false - 切勿写
Co::sleep(1); $chan->pop();—— 这不能中断已挂起的 pop，只是白等一秒后才开始等
通道关闭后读写会抛出 Swoole\Error 异常
当调用 $chan->close() 后，所有后续对它的 pop() 或 push() 操作都会立即抛出 \Swoole\Error（非 Throwable 子类，但可被 catch (\Throwable) 捕获）。
- 关闭后
pop()抛出：Uncaught Swoole\Error: channel is closed - 关闭后
push()抛出：Uncaught Swoole\Error: channel is closed - 建议在关键路径中用 try-catch 包裹，尤其在多协程协作、资源清理阶段
- 注意：
$chan->__destruct()会自动 close，但显式调用更可控
结合超时与异常捕获的典型模式
生产环境中推荐将超时判断与关闭防护合并处理，避免因通道提前关闭导致未捕获异常中断流程。
- 先检查
$chan->isClosed()（Swoole ≥ 4.5.0 支持），再操作 - 统一用
try { $data = $chan->pop(3); } catch (\Throwable $e) { /* 记录日志并退出 */ } - 超时返回
false时，应主动判断是否需退出协程或重试，而非忽略 - 使用
defer确保通道在协程退出前被正确 close，防止泄漏
通道关闭不等于协程终止，需协同退出逻辑
Channel 关闭本身不会杀死协程，只是让后续 I/O 失败。真正的退出需靠业务逻辑驱动：
- 不要依赖“对方关了通道，我自然就停了”——必须自己检查返回值或异常后
return - 常见做法：父协程 close 通道后，向子协程发送 shutdown 信号（如 push
['cmd' => 'quit']），子协程收到后 clean exit - 避免在
__get/__set或其他魔术方法中调用pop/push，可能引发不可预期的协程切换和异常
