必须选 yii\queue\amqp_interop\Queue——它是Yii官方唯一活跃维护的AMQP驱动，兼容PHP 8+和RabbitMQ 3.10+，解决旧驱动因协议不匹配导致的TLS/vhost/SASL失败、FRAME_END missing等静默错误。
直接用 yii\queue\amqp_interop\Queue，别碰 yii\queue\amqp\Queue——后者已停更，连 TLS 和 vhost 都容易炸。
为什么必须选 amqp_interop 驱动
旧驱动 yii\queue\amqp\Queue 依赖过时的 enqueue/amqp-lib 分支，而新版 yii\queue\amqp_interop\Queue 是 Yii 官方当前唯一活跃维护的 AMQP 实现，原生支持 PHP 8+、RabbitMQ 3.10+，且底层协议栈与现代 RabbitMQ 的 heartbeat、SASL、vhost 路径解析完全对齐。
常见错误现象包括：AMQP protocol error: FRAME_END missing、Connection refused、或连接后立即断开——八成是驱动协议不匹配导致的静默失败。
如果你本地装了 amqp.so 扩展，反而要禁用它：在 php.ini 中注释掉 extension=amqp.so，否则会和纯 PHP 实现的 enqueue/amqp-lib 冲突，报 Class 'AMQPConnection' not found。
console/config/main.php 里怎么配才生效
'bootstrap' => ['queue'] 必须放在 console/config/main.php 的根级（即和 'components' 同级），不能塞进 'components' 里，也不能写在 web/config/main.php 中——Web 端加这个配置不仅无效，还会引发 Cannot use object of type yii\queue\amqp_interop\Queue as array 这类诡异错误。
队列组件本身要这样声明：
'components' => [
'queue' => [
'class' => 'yii\queue\amqp_interop\Queue',
'dsn' => 'amqp_interop:amqp://guest:guest@localhost:5672/%2F',
'ttr' => 300,
'attempts' => 3,
],
],
注意几点：
-
dsn中的 vhost 必须 URL 编码，/要写成%2F，否则连接会卡在认证阶段 -
ttr是单次任务执行最大秒数，不是“超时重试”，超了就 kill 进程并计入attempts -
attempts => 3意味着该任务最多被投递 3 次（含首次），失败后默认延迟约 1 秒再入队，间隔不可调
消费者进程必须带 --verbose 启动
用 Supervisor 或 systemd 管理消费者时，命令必须是：
php yii queue/listen --verbose
漏掉 --verbose，任务失败时既不打印错误堆栈，也不退出进程，结果就是“看起来在跑，其实卡死”。这是线上最常被忽略的部署细节。
还要确认 console/controllers/QueueController.php 存在——它是 yii2-queue 自带的，但若被误删或覆盖，yii queue/listen 命令会直接报错“unknown command”。
ttr 设太小会导致任务被粗暴终止
比如一个导出报表的任务平均耗时 4 分钟，你设 ttr => 240（4 分钟），看似刚好，但网络抖动、MySQL 锁等待、临时 GC 都可能让单次执行突破阈值。一旦超时，PHP 进程被信号强制终止，上下文全丢，无法续跑。
建议按实际平均耗时 × 1.5～2 设置，但上限别超过 RabbitMQ 的 heartbeat（默认 60s）——否则连接层先断，驱动层还傻等，反而更难诊断。
真正棘手的是：这种超时不会留下明显日志，只会在 RabbitMQ 管理界面看到消息反复入队又消失，排查时容易绕进网络或权限问题里打转。
