laravel 的 php-amqplib 不支持动态绑定死信交换机，必须预声明队列并配置 x-dead-letter-exchange 参数；不同任务需通过多连接预建队列实现差异化死信路由。
死信交换机和队列必须提前声明，不能动态绑定
直接说结论：Laravel 的 php-amqplib 底层（包括 vladimir-yuldashev/laravel-queue-rabbitmq）不支持在消费或推送消息时「临时创建并绑定」死信交换机（DLX）或死信路由键（DLK）。死信机制依赖 RabbitMQ 的队列声明参数，必须在队列创建时通过 x-dead-letter-exchange 和 x-dead-letter-routing-key 指定，而 Laravel 的队列驱动默认只在首次启动 worker 时声明队列——之后再改参数无效，RabbitMQ 会拒绝修改已存在队列的参数。
常见错误现象：
• 修改 config/queue.php 中的 dead_letter_exchange 后重启 worker，旧队列仍沿用老配置
• 在 dispatch() 时试图用 ->onConnection('rabbitmq')->delay(…) 触发死信，但实际没走 DLX
• 日志里出现 PRECONDITION_FAILED - inequivalent arg 'x-dead-letter-exchange' for queue
如何为不同任务类型配置不同死信路由
核心思路是「按业务维度预建多个队列」，每个队列绑定专属的 DLX/DLK。不是靠代码运行时绑定，而是靠队列名隔离 + 配置驱动声明。
- 在
config/queue.php的rabbitmq连接下，定义多个子连接，例如：'connections' => [ 'emails' => [ 'worker' => 'default', 'queue' => 'emails', 'dead_letter_exchange' => 'dlx.emails', 'dead_letter_routing_key' => 'dlq.emails.failed', ], 'notifications' => [ 'worker' => 'default', 'queue' => 'notifications', 'dead_letter_exchange' => 'dlx.notifications', 'dead_letter_routing_key' => 'dlq.notifications.timeout', ], ] - 投递任务时显式指定连接：
EmailJob::dispatch()->onConnection('emails'); NotificationJob::dispatch()->onConnection('notifications'); - 确保首次运行
php artisan queue:work rabbitmq:emails时，该连接对应的队列被声明（含 DLX 参数），后续所有同名队列复用此声明
手动触发死信的唯一可靠方式：reject + requeue = false
当业务逻辑判定某条消息应进死信队列（比如重试 3 次失败），不能靠抛异常自动处理——Laravel 默认会把异常消息放回原队列（requeue=true），这不是死信。必须在 handle() 中主动拒绝并禁止重入：
public function handle()
{
try {
// 处理逻辑
} catch (Exception $e) {
if ($this->attempts() >= 3) {
// 主动拒绝且不重入 → 触发死信路由
throw new \RuntimeException('Max attempts reached', 0, $e);
}
throw $e; // 让框架自动重试
}
}
注意：
• 必须用 throw（不是 return 或 Log::error()）
• 异常必须未被捕获到 job 外层（否则框架收不到失败信号）
• 确保 config/queue.php 中对应连接的 retry_after 足够长，避免超时强制 reject
调试死信是否生效的关键检查点
死信机制静默失败很常见，重点查这三处：
- RabbitMQ 管理界面中，目标队列的
Arguments栏是否真实显示x-dead-letter-exchange=dlx.xxx（不是配置写了就算数） - 死信交换机
dlx.xxx是否已存在且类型为direct（DLX 必须是 direct 或 topic，fanout 不行） - 死信路由键指向的最终队列（如
dlq.emails.failed）是否已声明，并绑定到 DLX 上（用queue_bind命令或管理界面确认） - 消息 TTL（
x-message-ttl）若也设置了，它和死信是并行触发条件，别混淆“超时死信”和“拒绝死信”
最易忽略的是：DLX 和 DLQ 的声明顺序。必须先有 DLX，再声明带 DLX 参数的业务队列，否则声明失败；而 Laravel 默认不会帮你建 DLX，得用 php artisan rabbitmq:setup-exchanges（如果用了扩展包）或手写 php artisan tinker 调用 AMQPExchange::declareExchange()。
