channel::push/pop 必须设超时，否则协程卡死；推荐 push($data, 500)、pop(500)，避免0超时；需用swoole\coroutine\channel（≥2.0.13），并校验返回值防fatal error。
Channel::push 超时会卡死协程，必须设上限
当 Channel 缓冲区已满，push() 默认无限等待空位，协程挂起不返回，整个进程可能因大量堆积而失去响应。这不是“慢”，而是不可控阻塞。
- 务必传入超时毫秒数，例如
$chan->push($data, 500)，超过 500ms 直接返回false - 别用
0期望“立即失败”——它在某些版本中语义模糊，部分场景仍可能 yield；明确用1或10更可靠 - 业务层需检查返回值：
if (!$chan->push($data, 500)) { /* 降级写日志 / 丢弃 / 重试 */ } - 缓冲区容量
$capacity不是越大越好：设为 100 却每秒 push 200 次，超时率必然飙升；应按峰值生产速率 × 平均处理延迟反推
Channel::pop 超时设置不当导致 CPU 拉满
pop() 在空通道上默认也无限等待，但更危险的是有人误设 $chan->pop(0) 想做“非阻塞尝试”，结果协程高频轮询，CPU 瞬间 100%，却无实际数据消费。
- 推荐统一用
$chan->pop(500)：500ms 内没数据就放弃，避免空转 - 若业务允许延迟，可设为 1000–3000，配合
while循环重试，比0更可控 - 注意
pop()返回false的两种情况：超时 or 通道已close()，需用$chan->stats()辅助判断是否已关闭 - 不要在
pop()失败后立刻continue进入下一轮循环——加Co::sleep(0.01)避免忙等
协程 Channel 和 Swoole\Channel 的超时行为差异
这两个类名相似但行为不同：Swoole\Channel（旧版，PECL swoole ≥1.9.0）不支持超时参数，push/pop 全是阻塞式；而 Swoole\Coroutine\Channel（2.0.13+）才支持带超时的 push($data, $timeout) 和 pop($timeout)。
Send email using MailChannels Email API
下载
通过 MailChannels Email API 发送邮件，并将已签名的投递事件 Webhook 接收至 Clawdbot (Moltbot)。
- 确认你用的是
use Swoole\Coroutine\Channel，不是Swoole\Channel - 运行
php --ri swoole查版本，低于 2.0.13 的必须升级或改用Channel+ 外部超时控制（如Co::wait()包裹） -
Swoole\Channel的pop()即使通道为空也不会报错，只是永远挂起——这种“静默卡死”最难排查
超时异常没被捕获，协程直接退出
当 pop() 或 push() 超时，返回 false，不会抛异常；但若你在后续代码里直接对这个 false 做数组访问或方法调用，就会触发 Fatal error，且该协程静默终止，不报错也不通知。
- 永远先判断：
$data = $chan->pop(500); if ($data === false) { /* 处理超时 */ return; } - 避免
$data['id']这类操作前不校验，可改用$data ?? []或is_array($data) - 协程内未捕获的
Fatal error不会冒泡到外层，try/catch无效；只能靠前置防御和日志error_log("pop timeout at cid=".Co::getCid())定位
超时值不是拍脑袋定的数字，它得贴合你的协程处理链路耗时——比如下游 MySQL 查询 P99 是 120ms，那 Channel pop 超时设 200ms 就很合理；设成 50ms 会导致大量误判，设成 5000ms 又拖慢整体响应。真正难的从来不是写 500 这个数字，而是搞清这 500ms 在你整个请求生命周期里到底处在哪一环。
