AMQPQueue::consume() 不支持超时参数，必须通过 $channel->set_timeout() 设置 socket 级读超时；否则网络异常时会阻塞卡死，需配合异常捕获与 channel 重建实现健壮消费。
AMQPQueue::consume() 本身不支持超时参数，必须靠 $channel->set_timeout() 控制底层连接级超时。
为什么不能直接在 consume() 里设超时
AMQPQueue::consume() 是阻塞式等待消息的调用，它没有提供类似 timeout 的函数参数。传入回调后，它会一直等，直到有消息到达或连接异常中断。你写 $queue->consume($cb, AMQP_AUTOACK)，看起来是“监听”，但实际是单次拉取 + 回调触发，不是长连接保活机制。
常见错误现象：网络抖动、RabbitMQ临时不可达时，consume() 卡住不动，PHP进程假死，CPU不高但完全无响应。
根本原因在于 php-amqplib 底层依赖 TCP socket 等待数据，而 socket 默认阻塞且无读超时，必须显式设置。
立即学习“PHP免费学习笔记（深入）”；
正确设置超时：用 $channel->set_timeout()
必须在调用 consume() 前，对当前 channel 设置 socket 级读超时（单位：秒），这是唯一有效方式：
-
$channel->set_timeout(30)—— 推荐值，30 秒内无消息或网络中断就抛出AMQPTimeoutException - 这个超时影响所有后续 channel 操作，包括
basic_get()、consume()、wait() - 超时后不会自动重连，需手动捕获异常并重建 channel（或 connection）
- 注意：不是
$connection->set_timeout()，那是无效的；必须是$channel实例
配合 consume() 的健壮写法
单纯设 timeout 不够，还要处理异常退出和重试逻辑。典型 CLI 消费者结构如下：
while (true) {
try {
$channel->set_timeout(30);
$queue->consume($callback, AMQP_AUTOACK);
} catch (\PhpAmqpLib\Exception\AMQPTimeoutException $e) {
// 超时，可记录日志，继续下一轮
error_log('Channel timeout, retrying...');
continue;
} catch (\PhpAmqpLib\Exception\AMQPConnectionClosedException $e) {
// 连接断开，需重建 connection 和 channel
$connection = new AMQPStreamConnection(...);
$channel = $connection->channel();
$queue = $channel->queue_declare(...);
continue;
}
}
关键点：
- 不要用
while(true) { $queue->consume(...) }无限循环，不设超时等于裸奔 - 不要在 Web 请求中跑
consume()，Nginx/Apache 的请求超时（如 60s）会直接 kill 进程，导致消息丢失 - 生产环境务必用 supervisor 或 systemd 守护该脚本，保证崩溃后自动拉起
容易被忽略的细节
超时值不是越大越好。设成 300 秒（5 分钟）看似稳妥，但会导致故障发现慢、资源占用久、监控告警延迟。更危险的是：如果 RabbitMQ 正在重启，客户端卡在超时等待中，所有 worker 都 hang 住，形成雪崩。
真正关键的不是“等多久”，而是“超时后怎么做”——是否清空 channel、是否重连、是否记录失败上下文、是否丢弃/重发消息。这些逻辑比 timeout 数值本身更重要。
