死信队列必须手动声明并绑定，rabbitmq仅转发消息而不自动创建dlq；需显式声明死信交换器和队列、正确绑定routing key、使用amqp.table传参、确保x-dead-letter-exchange存在且大小写一致、x-message-ttl单位为毫秒、消费者拒收时requeue必须为false。
死信队列不是自动创建的，必须手动声明并绑定；RabbitMQ 只转发消息，不帮你建 DLQ —— 你漏掉任意一个环节（比如没声明死信交换器、参数类型写错、TTL 单位搞混），消息就直接消失，不会进 DLQ。
必须显式声明死信交换器和队列
很多人以为只要在原队列里设了 x-dead-letter-exchange，RabbitMQ 就会“自动配好”死信链路。实际不是：它只负责投递，前提是目标 Exchange 和 Queue 已存在且绑定正确。
-
dead_exchange必须提前用ExchangeDeclare声明，类型通常选amqp.ExchangeDirect或amqp.ExchangeTopic，且durable设为true -
dead_queue必须用QueueDeclare显式创建，autoDelete和exclusive都得是false，否则重启后队列消失，后续死信无处可去 -
QueueBind调用不能省：把dead_queue绑定到dead_exchange，routingKey必须和原队列设置的x-dead-letter-routing-key完全一致
原队列声明时 args 必须用 amqp.Table 传参
Go 的 amqp-go 库对死信参数极其敏感：必须用 amqp.Table 类型（本质是 map[string]interface{}），写成普通字符串或结构体字段会被静默忽略 —— 不报错，但参数无效。
-
x-dead-letter-exchange值必须是已存在的 Exchange 名字（字符串），拼错或大小写不符就失效 -
x-dead-letter-routing-key如果为空，RabbitMQ 默认沿用原消息的 routing key；设了就必须和 DLQ 的绑定 key 匹配，否则消息被丢弃 -
x-message-ttl单位是毫秒，常见错误是写成秒（比如想延迟 30 秒，写了30而不是30000） - 别在死信队列上再设
x-message-ttl—— 进入 DLQ 的消息若再次过期，会被直接丢弃
消费者拒收必须用 Reject(false) 或 Nack(false)
只有 requeue=false 才触发死信；Reject(true) 或 Nack(true) 是把消息重新入队，不走 DLQ 流程。
- 调用
msg.Reject(false)或msg.Nack(false)后，消息才可能进死信队列 - 如果启用了 manual ack（
autoAck=false），又忘了 ack/nack，消息会一直卡在 unacked 状态，既不消费也不变死信 - TTL 过期和队列满（
x-max-length）也会触发死信，但这两者不依赖消费者行为，适合做纯延迟场景
最常被忽略的是参数类型和绑定一致性：amqp.Table 构造不对、DLQ 绑定 key 和 x-dead-letter-routing-key 对不上、死信 Exchange 没声明 —— 这三类问题占了 80% 的“消息消失”案例。调试时先查管理界面里四个实体（normal exchange/queue、dead exchange/queue）是否存在且绑定关系正确，再看原队列的 arguments 是否生效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
