HTTP客户端请求失败时，err不一定代表网络断开；4xx/5xx状态码下err为nil，需检查resp.StatusCode；真正需重试的是net.OpError、context超时等底层错误，且须保障幂等性。
HTTP客户端请求失败时，err 不一定代表网络断开
Go 的 http.Client.Do() 在多数错误下会返回非 nil 的 err，但要注意：当服务器返回 4xx/5xx 状态码（如 404、502）时，err 仍为 nil，错误藏在 resp.StatusCode 里。真正需要重试的，往往是底层连接问题，比如 net/http: request canceled、context deadline exceeded、connection refused 或 i/o timeout。
判断是否值得重试，建议用以下方式：
- 检查
err是否为nil；不为nil时再用errors.Is(err, context.DeadlineExceeded)或errors.Is(err, context.Canceled)判断是否超时/取消 - 对
err做字符串匹配要谨慎，优先用errors.As()提取底层*url.Error或*net.OpError - 若
err == nil但resp.StatusCode >= 400，通常不应重试（比如401是认证失败，重试无意义）
用 http.Client 配合 context.WithTimeout 控制单次请求生命周期
默认的 http.Client 没有超时，容易卡死。必须显式设置超时，且推荐用 context 而非 Client.Timeout 字段——后者只控制连接+读取，不涵盖 DNS 解析、TLS 握手等全链路耗时。
正确写法示例：
立即学习“go语言免费学习笔记（深入）”；
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) defer cancel()req, _ := http.NewRequestWithContext(ctx, "GET", "https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca", nil) resp, err := http.DefaultClient.Do(req)
注意：context.WithTimeout 创建的 ctx 会在超时后自动触发 cancel()，此时 Do() 返回 context.DeadlineExceeded 错误。不要忽略 cancel() 调用，否则可能泄漏 goroutine。
实现指数退避重试时，避免用 time.Sleep 硬阻塞
简单 for-loop + time.Sleep 容易阻塞整个 goroutine，且无法响应外部取消。应把重试逻辑封装进带 context 的循环中，并使用 time.AfterFunc 或 select 等待间隔。
关键点：
- 每次重试前生成新
context，继承原始ctx并叠加本次重试超时（例如 3 秒），防止某次重试拖垮整体 deadline - 退避时间用
time.Duration(math.Pow(2, float64(attempt))) * time.Second计算，但上限建议设为 10 秒，避免过长等待 - 重试次数建议 ≤ 3 次；超过后直接返回原始错误，别硬扛
- 对
503 Service Unavailable这类明确提示“稍后再试”的状态码，可额外检查resp.Header.Get("Retry-After")
不要在中间件里全局重试所有 HTTP 错误
Web 框架（如 Gin、Echo）的中间件里做统一重试看似方便，实则危险：它会把用户请求重复转发给下游服务，可能造成幂等性破坏（比如重复扣款、重复发消息）。重试必须由业务层决策，且仅限于明确可重试的场景，例如：
- 调用第三方支付回调通知失败（对方要求成功响应才认为送达）
- 向内部服务查询缓存状态时临时连不上（该操作本身无副作用）
- 上传文件到对象存储时因网络抖动中断（需配合断点续传或唯一 ID 去重）
最常被忽略的一点是：重试必须携带相同请求标识（如 X-Request-ID），并确保下游能识别并去重。没有幂等保障的重试，比不重试更糟。
