go 的 http.client 默认不重试，需手动实现；仅对幂等请求和特定网络错误（如 net.operror）重试，配合指数退避加 jitter、最大次数/时间限制，并用 backoff 库更稳妥。
Go 的 http.Client 默认不重试，必须手动实现
HTTP 请求失败时，http.Client 会直接返回错误，不会自动重试。这是设计使然——重试可能引发副作用（比如重复下单），所以 Go 把决策权完全交给你。
常见错误现象：Post "https://api.example.com": context deadline exceeded 或 read: connection reset by peer 出现一次就中断，没机会恢复。
实操建议：
- 用
context.WithTimeout或context.WithDeadline控制单次请求上限，避免重试卡死 - 只对幂等方法（
GET、HEAD、PUT）考虑重试；POST需业务层确认是否可重发 - 别在
http.Transport层试图“全局开启重试”，它不支持，也违背语义
指数退避要用 time.Sleep + 带 jitter 的随机偏移
纯指数增长（100ms → 200ms → 400ms）会导致重试请求在服务端形成“脉冲”，尤其多实例并发时容易雪崩。
立即学习“go语言免费学习笔记（深入）”；
使用场景：调用外部 API、依赖第三方服务的内部网关、K8s 中访问 etcd 等。
实操建议：
- 基础退避：第 n 次重试睡
time.Duration(math.Pow(2, float64(n))) * time.Second - 必须加 jitter：用
rand.Float64() * 0.3乘上当前间隔，避免同步重试 - 设最大重试次数（如 5 次）和最大间隔（如 3s），防止退避失控
- 别用
time.AfterFunc做异步重试，容易泄露 goroutine；用循环 +select等待更可控
net/http 错误类型要区分处理，不是所有错误都该重试
同一个 error 接口背后可能是网络断开、DNS 失败、TLS 握手超时、甚至 JSON 解析失败——后两者重试毫无意义。
常见错误现象：json: cannot unmarshal string into Go struct 被当成网络错误反复重试，浪费资源又掩盖真实问题。
实操建议：
- 先检查
err == nil，再判断resp != nil；非 2xx 响应体也要读完并关闭resp.Body - 用类型断言识别底层错误：
if urlErr, ok := err.(*url.Error); ok && urlErr.Err != nil - 只对以下错误重试：
net.OpError（连接/读写失败）、net.DNSError、http.ErrHandlerTimeout - 遇到
io.EOF、json.SyntaxError、status code 400/401/403等，直接返回，不重试
用 backoff.Retry（github.com/cenkalti/backoff/v4）比手写更稳
手写退避逻辑容易漏掉上下文取消、jitter 实现偏差、goroutine 泄露等细节。社区库已覆盖多数边界情况。
性能 / 兼容性影响：v4 版本支持 context.Context，无额外依赖，二进制体积增加可忽略。
实操建议：
- 初始化时用
backoff.WithContext(backoff.NewExponentialBackOff(), ctx)绑定上下文 - 把 HTTP 请求封装成无参函数传给
backoff.Retry，让它控制重试时机 - 注意：该库默认最大重试时间是 30 分钟，需显式设置
MaxElapsedTime（如30 * time.Second） - 不要在重试函数里复用
http.Client的Transport，除非你确认它支持并发且没被关闭
最易被忽略的是：重试时的请求体（尤其是 io.Reader 类型）不可复用。比如用 strings.NewReader 没问题，但用 bytes.Reader 后续重试会读空——得每次新建。这点连不少老手都会栽。
