必须用dlx+ttl+header计数三者配合实现可控重试：声明重试队列时设x-message-ttl和x-dead-letter-exchange，失败时更新retry_count头并publish至重试队列，超次则进死信队列，禁用autoack且手动ack/nack。
不能只靠 basic.nack(requeue=true) 循环重试，必须用 DLX + TTL + header 计数三者配合，否则不是“可控重试”，而是“消息雪崩”或“静默丢弃”。
声明重试队列时必须设 x-message-ttl 和 x-dead-letter-exchange
消息级 expiration 属性在 Go 客户端（如 streadway/amqp）中不可靠：它依赖于 publisher 设置且不被所有 broker 版本一致支持。真正生效的是队列级 TTL —— 它让整条队列里的待消费消息统一倒计时。
- 重试队列（比如
retry.queue）声明时，args必须包含："x-message-ttl": 5000（单位毫秒）、"x-dead-letter-exchange": "original-exchange"、"x-dead-letter-routing-key": "original.routing.key" -
x-dead-letter-exchange通常设为业务主交换器（而非新建一个 DLX），避免多层转发带来的路由歧义 - 死信队列本身不用设 TTL，它只是个普通队列，用于归档最终失败的消息
消费者处理失败时必须 reject 或 nack 且 requeue=false
Go 的 amqp.Channel 不会因为你 panic 或 return 就自动进死信。你得主动控制消息生命周期：
- 临时错误（如 HTTP 503、DB 连接超时）：更新
msg.Headers["retry_count"]，再ch.Publish到重试队列，然后msg.Ack() - 永久错误（如 JSON 解析失败、400 参数非法）：直接
ch.Reject(msg.DeliveryTag, false)或ch.Nack(msg.DeliveryTag, false, false)，其中第二个false表示requeue=false - 千万别写
ch.Nack(..., true)—— 这会让消息立刻回到原队列头部，造成高频循环，压垮消费者
重试次数必须存在 message header 里，不能用局部变量
Go 程序重启、K8s Pod 重建、消费者扩缩容都会清空内存。RabbitMQ 唯一能跨队列携带状态的地方是 msg.Headers。
- 首次投递时，在
amqp.Publishing.Headers中设："retry_count": 0 - 每次重试前读取并递增：
count := msg.Headers["retry_count"].(int); count++ - 若
count >= 3，不再发回重试队列，改发到死信交换器或落库记录：ch.Publish("dl-exchange", "dl.routing.key", false, false, amqp.Publishing{}) - 避免把 retry_count 塞进 JSON body：一旦反序列化失败，整个消息卡住；header 缺失只会返回 nil，默认值可安全 fallback
手动 ACK 是底线，AutoAck = true 在生产环境等于放弃重试能力
开启 AutoAck 意味着消息一推送给消费者就从队列删除。哪怕你的 handler panic 了，RabbitMQ 也认为“已成功消费”，根本不会触发任何重试逻辑。
- 所有生产消费者必须设
amqp.Qos(1, 0, false)+ch.Consume(..., autoAck=false) - 成功路径：处理完业务 →
msg.Ack() - 失败路径：分类判断 → 更新 header 或 reject →
msg.Ack()（注意：无论成功失败，都要 Ack/Nack，否则 unacked 消息堆积）
最容易被忽略的点是：TTL 只对“未被消费者取走”的消息生效。一旦 ch.Consume 拿到消息，它就在消费者内存里，RabbitMQ 不再监控其超时。所以延迟重试必须靠“先拒收 → 进带 TTL 队列 → 过期后自动转投”，而不是指望消息在 consumer 手里等 5 秒再 reject。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
