默认重试逻辑在生产环境大概率失效，因go标准库无内置重试机制，简单for循环+sleep易引发重试风暴或漏判；需精准区分错误类型、合理配置transport、实施指数退避与随机抖动，并通过isretryableerror函数统一判断可重试性。
为什么默认重试逻辑在生产环境大概率失效
Go 标准库没有内置重试机制，http.Client 的 Do 方法失败就直接返回错误。很多人写个 for 循环 + time.Sleep 就交差，结果在高并发下要么雪崩（重试风暴），要么漏判（把 400 当成可重试错误）。关键在于：不是所有错误都该重试，也不是所有错误都能靠等几秒解决。
区分错误类型比重试次数更重要
必须在重试前检查 err 的底层类型和状态码，否则重试毫无意义。常见误判包括：
-
url.Error中的Timeout()返回 true → 可重试 -
net.OpError的Err是syscall.ECONNREFUSED或syscall.ETIMEDOUT→ 可重试 -
http.Response.StatusCode是 502/503/504 → 可重试 -
http.Response.StatusCode是 400/401/404 → 不该重试（客户端问题） -
err == nil但resp.StatusCode >= 400→ 需单独处理，不能跳过
建议封装一个 isRetryableError(err error, resp *http.Response) bool 函数，把判断逻辑收口，避免散落在各处。
Transport 层配置比业务层重试更关键
很多 EOF、connection reset 问题根本不在业务逻辑里，而在连接复用策略上。不配好 http.Transport，再聪明的重试也白搭：
-
MaxIdleConns和MaxIdleConnsPerHost设太小 → 连接池不够用，频繁建连触发超时 -
IdleConnTimeout设太长（如 90s）→ 服务端已关闭连接，客户端还傻等复用，下次请求直接 EOF - 没设
TLSHandshakeTimeout→ TLS 握手卡住时，整个请求无响应，超时控制失效 - 没设
ResponseHeaderTimeout→ 响应头迟迟不来，但 body 可能永远读不到，goroutine 泄漏
生产环境推荐值：IdleConnTimeout: 30 * time.Second，TLSHandshakeTimeout: 10 * time.Second，ResponseHeaderTimeout: 5 * time.Second。
指数退避 + 随机抖动必须落地到每次重试
固定间隔重试（如每次都 sleep 1s）会放大系统压力，尤其在服务端已过载时。必须用指数增长 + 随机偏移：
sleepTime := math.Pow(2, float64(retry)) * baseDelay jitter := rand.Float64() * 0.5 * sleepTime time.Sleep(time.Duration(sleepTime+jitter) * time.Second)
注意两点：一是 rand 要用 rand.New(rand.NewSource(time.Now().UnixNano())) 避免多个 goroutine 共享全局 seed 导致抖动失效；二是首次重试延迟别设为 0，至少 100ms，给服务端喘息时间。
真正难的是错误分类边界的模糊性——比如 500 错误，有些是服务端 panic，重试无用；有些是 DB 连接池满，重试有效。这类情况没法全自动判断，得靠日志标记 + 人工反馈闭环，代码里留好钩子比硬编码更实际。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
