死信消息的路由键由x-dead-letter-routing-key决定，而非原始routing key；若未显式设置，则默认使用队列名，易导致匹配失败或逻辑混乱，故必须在queuedeclare时通过args显式配置。
死信消息的路由键由 x-dead-letter-routing-key 决定，不是原消息的 routing key
很多人误以为死信会自动沿用原始消息的 routing_key 转发到死信交换机，实际不会。RabbitMQ 在将消息转为死信并投递到 DLX（Dead Letter Exchange）时，**完全忽略原始 routing key**，改用队列声明时指定的 x-dead-letter-routing-key 值作为新 routing key。这个值必须和死信交换机的绑定规则匹配，否则消息会被丢弃（尤其在 Direct 或 Topic 类型下）。
比如你声明了一个普通队列 order.queue，绑定了 order.exchange，原始 routing key 是 order.created；但你在该队列上设置了：{"x-dead-letter-exchange": "dlx.exchange", "x-dead-letter-routing-key": "dlq.order.failed"}
那么哪怕原始消息是通过 order.created 进来的，变成死信后，RabbitMQ 会以 dlq.order.failed 为 routing key 发往 dlx.exchange —— 所以你的死信队列必须用这个 key 绑定到 dlx.exchange，否则收不到。
x-dead-letter-routing-key 不填会发生什么？
如果不显式设置 x-dead-letter-routing-key，RabbitMQ 默认使用**原队列名**作为死信 routing key。这容易踩坑，因为：
- 如果你的死信交换机是 Direct 类型，而死信队列只绑定了
dlq.order，但原队列叫order.queue，那默认 routing key 就是order.queue，根本匹配不上 - 如果死信交换机是 Topic 类型，且你绑定了
dlq.#，那默认的队列名可能意外匹配（比如order.queue匹配order.*），看似能收到，但逻辑不可控、难维护 - 不同业务队列名风格不一（如
user.event.v1、payment_timeout_queue），默认行为会导致死信散落到多个绑定路径，排查混乱
所以强烈建议**显式设置**，且保持语义清晰，例如 dlq.payment.timeout、dlq.user.validation.rejected。
如何验证 x-dead-letter-routing-key 是否生效？
最直接的方式是开启 RabbitMQ 的 Web 管理界面，进到对应队列的 “Features” 标签页，查看 Arguments 区域是否包含你设置的 x-dead-letter-routing-key 值。注意：这个参数是队列级声明参数，必须在 queueDeclare 时传入 args Map，不能后期修改（除非删队列重建）。
常见错误写法：
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
channel.queueDeclare("my.queue", true, false, false, null); // ❌ args 为 null，没设 routing key
正确写法（Java）：
Map<string object> args = new HashMap();
args.put("x-dead-letter-exchange", "dlx.exchange");
args.put("x-dead-letter-routing-key", "dlq.order.expired");
channel.queueDeclare("order.queue", true, false, false, args); // ✅</string>
另外，可通过 rabbitmqctl list_queues name arguments 命令行确认参数是否已生效。
和消息级 TTL 配合时，x-dead-letter-routing-key 还管用吗？
管用，而且更关键。当消息设置了 per-message TTL（比如 Expiration: "60000"），它过期后变成死信，此时 RabbitMQ 同样会丢弃原始 routing key，严格使用队列定义的 x-dead-letter-routing-key 转发。这意味着：
- 即使你用同一个交换机发多种消息（
order.pay、order.cancel、order.refund）到同一个队列，只要队列只设了一个x-dead-letter-routing-key，所有过期消息都会走同一路由路径 - 若想按类型分流死信，得拆成多个队列，每个队列配不同的
x-dead-letter-routing-key和绑定关系 - 不要指望靠消息头（headers）或 body 内容来动态改 routing key —— RabbitMQ 的 DLX 机制不支持运行时解析
真正需要区分死信原因的场景，建议在消费者拒绝时主动带 context（比如 nack 时发一个新消息到专用 topic），而不是依赖 DLX 的 routing key 做分类。
