默认 http.Client 不支持自动重试，需手动封装以避免雪崩；retryablehttp 默认不重试429/408，需自定义CheckRetry；手写重试须控制重试条件、指数退避、上下文取消及外层总超时。
为什么默认的 http.Client 不够用
Go 标准库的 http.Client 本身不处理失败重试，遇到网络抖动、服务端 503 或超时就直接返回错误。你得自己封装逻辑，否则调用方要反复写重试代码，容易漏掉退避（backoff）或指数退避控制，导致请求雪崩。
关键点在于：重试必须带延迟，且延迟不能固定——连续快速重试对下游毫无帮助，还可能加重故障。
retryablehttp 库能省事但要注意配置陷阱
社区常用 retryablehttp（hashicorp/retryablehttp），它基于标准 http.Client 封装，支持自定义重试条件、退避策略和最大重试次数。但它默认只对连接错误和 5xx 响应重试，**不会重试 429（Too Many Requests）或 408（Request Timeout）**，这点常被忽略。
- 启用 429 重试需显式设置
RetryMax和CheckRetry回调，例如判断resp.StatusCode == 429 - 退避默认是指数增长（1s, 2s, 4s…），但初始值是 100ms；若设
Backoff: retryablehttp.LinearJitterBackoff，会变成固定间隔+随机抖动，适合压测场景 - 别忘了设置
HTTPClient.Transport的IdleConnTimeout和MaxIdleConnsPerHost，否则重试期间可能堆积大量空闲连接
手写轻量版重试客户端的关键三步
如果不想引入第三方依赖，用标准库也能写出可靠重试逻辑，核心是控制好「何时重试」「等多久」「最多几次」。
- 用
time.AfterFunc或time.Sleep实现退避，推荐从time.Second开始，每次乘以 2（指数退避），上限建议 30s 防止卡死 - 重试判定不要只看
err != nil，还要检查resp.StatusCode：比如 500/502/503/504 和 429 可重试，400/401/404 则不该重试 - 务必在每次重试前检查上下文是否已取消（
ctx.Err() != nil），否则可能在ctx.WithTimeout过期后还在发请求
示例片段：
for i := 0; i < maxRetries; i++ {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if err == nil && resp.StatusCode < 500 && resp.StatusCode != 429 {
return resp, nil
}
if i == maxRetries-1 {
return resp, err
}
select {
case <-ctx.Done():
return nil, ctx.Err()
case <-time.After(time.Second * time.Duration(1<<i)): // 指数退避
}
}超时与重试的嵌套关系最容易出错
很多人把 http.Client.Timeout 和重试逻辑混在一起，结果发现：设了 5s 超时 + 最多重试 3 次，实际最长可能耗时 15s —— 因为每次 Do 都独立计时。
正确做法是用一个外层上下文统一控制总耗时：
- 创建
ctx, cancel := context.WithTimeout(parentCtx, 10*time.Second) - 所有
http.NewRequestWithContext(ctx, ...)都传这个ctx - 重试循环内部用
select监听ctx.Done()，而不是靠time.Sleep硬等
否则，最后一次重试刚发起，外层超时就到了，但请求还在跑，既浪费资源又无法及时释放连接。
重试逻辑看似简单，真正难的是边界控制：退避是否平滑、错误分类是否合理、上下文取消是否透传、连接复用是否被干扰——这些地方一松懈，客户端就从“容错”变成“捣乱”。
