Go 重试与退避：别让失败请求把流量放大三倍

重试能掩盖短暂抖动，但也会放大故障。当下游已经慢了，所有上游再重试三次，就等于把压力继续推高。重试策略必须有预算、有退避、有幂等。

只重试可恢复错误

网络短暂失败、连接重置、429/503 可能适合重试；参数错误、权限错误、业务校验失败不应该重试。

总时间必须受入口 deadline 控制

每次重试都要检查 context。如果剩余时间不足，就不要为了完成次数而继续重试。

写请求先谈幂等

没有幂等键的写请求，重试可能造成重复扣款、重复创建订单或重复发送消息。

生产场景

适用于短暂网络抖动、临时 503、429 和可恢复连接错误。重试必须服务于成功率，而不能在故障期把流量继续放大。

关键指标

• 重试次数、成功于第几次和最终失败比例
• 退避等待总耗时占请求预算比例
• 重试触发时下游错误率与 QPS 变化

常见误区

• 对所有错误无差别重试
• 写接口没有幂等键
• 入口已经超时仍继续完成剩余重试次数

落地建议

建议把 retryable 错误白名单写清楚，并加指数退避、抖动和总耗时上限。写操作必须先有幂等设计，故障期可通过熔断或限流暂停重试。

代码示例

for i := 0; i 

上线检查

• 重试次数和总耗时都有上限。
• 只重试明确可恢复错误。
• 写操作使用幂等键或去重表。