重试不应写在消费者 handler 中，而应基于 rabbitmq 的 dlx+ttl 实现可控延后重试；http 重试需用 retry-go 封装并精准分类错误，禁用 autoack、强制 qos 和显式 nack 才是生产级保障。
重试不该写在消费者 handler 里
直接在 RabbitMQ 消费函数里套 for 循环重试，是线上事故高发区。消息一旦失败，它既不通知 broker，也不进死信队列，更不会触发监控告警——它只是默默卡在 unacked 状态，直到 channel 关闭才可能被重发，行为完全不可控。
真正可靠的重试必须由 AMQP 协议层驱动，而不是靠 Go 的 goroutine 自己“努力”。核心动作只有两个：ch.Ack() 和 ch.Nack(false, true)。后者第二个参数 true 表示重入队列头部，但这是临时方案，不能替代 DLX+TTL 的闭环设计。
- 禁用
amqp.AutoAck = true—— 这是消息丢失的头号原因 - 启动 consumer 时必须调用
ch.Qos(1, 0, false)，限制未确认消息数为 1 - panic 或 error 必须用
recover()捕获，然后显式ch.Nack(false, true) - 别在 handler 里直接
return或忽略错误 —— 未 Ack 也未 Nack 的消息会滞留，无法追踪
RabbitMQ 的 DLX + TTL 才是生产级重试基础
重试不是“再试一次”，而是“可控地延后重试”。RabbitMQ 原生支持的 dead-letter-exchange（DLX）和队列级 x-message-ttl 是唯一能兼顾可观测性、可干预性和幂等性的方案。
关键点不在代码里怎么 sleep，而在于队列声明和消息流转路径是否正确：
- TTL 必须设在重试队列上（
Arguments: map[string]interface{}{"x-message-ttl": 10000}），而非 message 层 —— deliveryMode=2 不保证 TTL 生效 - 重试队列声明时必须绑定 DLX：
"x-dead-letter-exchange": "original-exchange" - 每次重试前更新
msg.Headers["retry_count"]，再 publish 到重试队列 —— 不能用局部变量存 retryCount，进程重启就丢 - 死信路由 key 必须和原始 binding key 一致，否则消息进不了原队列
HTTP 客户端重试要拦在 transport 层
在每个 http.Do() 外面手写 for 循环，等于把重试逻辑硬编码进业务函数。它污染逻辑、难复用、POST 请求体重放失败率高，还容易漏掉 req = req.Clone(req.Context()) 导致 context 丢失。
推荐用 github.com/avast/retry-go 的 retry.Do 封装，它自动处理 jitter、context 取消、错误过滤和次数控制：
-
retry.Attempts(3)表示总共执行 3 次（含首次），不是“重试 3 次” - 必须配
retry.Context(ctx)，否则context.DeadlineExceeded后还会继续重试 - 用
retry.RetryIf(func(err error) bool { return isTransientError(err) })替代字符串匹配，比如别写strings.Contains(err.Error(), "timeout") - 初始 delay 设
100 * time.Millisecond更友好 —— 首错等一秒，用户早点两次了
错误分类比重试逻辑本身更重要
重试的第一行代码，不应该是 for，而是判断函数 shouldRetry。很多系统崩在“所有错误都重试”，结果把 400、404、余额不足全补三枪，下游日志全是无效请求。
典型分类参考：
- 可重试：网络超时、
net.Error.Temporary()、HTTP502/503/504、429（但要看Retry-After） - 不可重试：
400/401/403/404、业务错误（如订单状态非法）、幂等缺失下的成功超时（扣款已执行但响应丢失） - 500 要谨慎：有些是空指针崩溃，重试只会更快压垮；有些是库存不足，重试无意义 —— 接口文档没写清楚，客户端别自作聪明
重试机制真正的复杂点不在退避算法，而在错误语义的理解和上下文生命周期管理。一个没做幂等的支付回调，重试三次就是三笔扣款。这问题没法靠加个 time.Sleep 解决。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
