死信队列需显式配置dlx和dlq：先声明dlx（如direct类型交换机），再声明dlq并绑定到dlx，最后在业务队列中通过x-dead-letter-exchange和x-dead-letter-routing-key参数指定路由，三者名称与键必须严格一致，否则死信将丢失。
死信队列不是开箱即用的功能，必须显式配置 DLX 和参数，否则消息被 reject 或过期后直接丢弃，不会自动进任何“默认死信队列”。
如何声明死信交换机（DLX）和死信队列（DLQ）
DLX 本身就是一个普通交换机，类型不限（direct、topic 都可以），关键在于它要和一个真实队列绑定，并且这个队列得能收消息。
常见错误是只声明了 dlx.exchange 却没绑定队列，或者绑定了但没设置 routing_key 匹配 —— 这会导致死信发出去后“石沉大海”，监控里看不到积压，消息实际已丢失。
- 先声明死信交换机：
channel.exchange_declare(exchange='dlx.exchange', exchange_type='direct') - 再声明死信队列：
channel.queue_declare(queue='dead.letter.queue', durable=True) - 最后绑定：
channel.queue_bind(exchange='dlx.exchange', queue='dead.letter.queue', routing_key='dlq.key')
如何给业务队列添加死信参数（x-dead-letter-*）
只有在声明业务队列时传入 x-dead-letter-exchange 和 x-dead-letter-routing-key，RabbitMQ 才知道“这条消息死了该往哪送”。这两个参数缺一不可，且值必须和上一步 DLX/DLQ 的声明完全一致。
容易踩的坑：参数名写错（比如漏掉 x- 前缀）、routing_key 大小写或拼写不匹配、DLX 名称用了未声明的字符串 —— 这些都会让死信静默失败，日志里通常只报 warning，不抛 error。
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
- 正确示例（Python pika）：
args = { "x-dead-letter-exchange": "dlx.exchange", "x-dead-letter-routing-key": "dlq.key" } channel.queue_declare(queue="order.queue", arguments=args) - 注意：如果还希望消息按 TTL 过期触发死信，需额外加
x-message-ttl（队列级）或发送时设expiration（消息级）
哪些场景下消息会真正变成死信？
不是所有消费失败都会进 DLQ。RabbitMQ 只在三种明确条件下标记死信，且必须满足对应行为逻辑：
-
basic.reject或basic.nack调用时传requeue=False；若传True，消息会重回原队列头部，不触发 DLX - 消息在队列中存活超时：由
x-message-ttl（队列级）或消息属性expiration控制；注意 TTL 是“在队列中停留时间”，不是“从生产开始计时” - 队列满载被挤出：设置
x-max-length后，新消息入队时，最早那条会被移出并作为死信处理；不是“满了就拒绝入队”，而是“满了就踢最老的”
还有一个隐性条件常被忽略：源队列必须是 durable 的，且 DLX/DLQ 也得是 durable 的，否则服务重启后配置丢失，死信路由中断。
为什么死信队列不能只靠“自动重试”解决？
很多人误以为加个 DLQ 就等于有了重试兜底，其实不然。DLQ 本质是隔离区，不是重试引擎 —— 它不自动转发、不修改消息内容、不重置重试次数。你得自己写消费者去读 dead.letter.queue，做人工干预、降级处理或发告警。
更关键的是：如果原始失败原因没修复（比如数据库宕机、下游接口 503），直接把死信重新发回原队列，大概率再次失败，形成循环。所以 DLQ 后的动作设计比配置本身更重要：要不要加人工审核？要不要记录原始错误堆栈？要不要按错误类型分流到不同处理队列？这些才是落地时最耗精力的部分。
