HTTP非2xx状态码需手动检查resp.StatusCode，推荐用isSuccessStatus封装判断；重试应使用backoff.Retry并区分错误类型，避免对400等客户端错误重试；RoundTripper中需克隆请求、复用body；context超时优先于Client.Timeout，建议禁用后者。
HTTP请求返回非2xx状态码时怎么判断和处理
Go 的 http.Client.Do 不会因为 HTTP 状态码非 2xx 而返回 error，它只在连接失败、超时、TLS 握手失败等底层问题时出错。这意味着 400、404、500 这类响应会正常返回，但你需要手动检查 resp.StatusCode。
常见错误是直接忽略 resp.StatusCode，只看 err == nil 就认为请求成功：
// ❌ 错误示范：没检查状态码
resp, err := client.Do(req)
if err != nil {
// 处理连接错误
return
}
// 此处 resp.StatusCode 可能是 502，但代码继续执行
body, _ := io.ReadAll(resp.Body)
- 建议统一用 helper 函数封装判断逻辑，比如
isSuccessStatus(resp.StatusCode)，只把200–299视为成功 - 对已知业务错误码（如
401、429），应提前分类处理，而不是扔进通用重试逻辑 - 注意：某些 API 用
200包装业务失败（如返回{"code": 500, "msg": "xxx"}），这时需解析响应体再判断
如何实现带退避的重试而不阻塞主线程
用 time.Sleep 在 goroutine 里硬等会浪费资源，尤其当重试间隔拉长（比如指数退避到几秒）时，goroutine 长时间挂起不划算。更合理的方式是用 time.AfterFunc 或结合 context.WithTimeout 控制生命周期。
关键点在于：重试逻辑必须可取消、可超时、且不泄漏 goroutine。
立即学习“go语言免费学习笔记（深入）”；
- 每次重试前检查
ctx.Err()，避免在上下文已取消后还发起请求 - 推荐用
backoff.Retry（来自github.com/cenkalti/backoff/v4），它内置 jitter 和最大重试次数，比手写 for+sleep 更可靠 - 不要对所有错误都重试：
net.OpError（连接拒绝）、context.DeadlineExceeded可重试；json.UnmarshalError或400 Bad Request属于客户端错误，重试无意义
自定义 http.RoundTripper 如何注入重试逻辑
想让所有请求自动带重试，又不想每个 http.Client.Do 都套一层 wrapper，可以实现自己的 http.RoundTripper。但要注意：标准 http.Transport 本身不支持重试，必须在 RoundTrip 方法里接管整个流程。
典型陷阱是复用 request body —— req.Body 是 io.ReadCloser，读过一次就 EOF，重试时会发空体。
- 若请求带 body（如 POST），必须用
req.GetBody（需提前设置req.Body = ioutil.NopCloser(...)并实现GetBody）或缓存 body 字节切片 - 不要在
RoundTrip里修改原始*http.Request，应clone后操作，否则并发下会出问题 - 重试时需更新
req.Header中可能变化的字段（如X-Request-ID），否则服务端难以区分重试请求
context.WithTimeout 和 http.Client.Timeout 哪个优先级更高
http.Client.Timeout 是整个请求的总时限（包括 DNS 解析、连接、TLS 握手、发送、接收），而 context.WithTimeout 是调用方设定的上层超时，两者同时存在时，**最先触发的那个生效**。
但实际中容易混淆的是：如果 Client.Timeout 设为 30s，context 设为 5s，你以为最多等 5s，结果发现有时卡到 30s 才返回 —— 这通常是因为 context 被 cancel 后，底层连接还在读响应体（尤其是大文件流式响应），而 Client.Timeout 并不会中断已建立连接的读操作。
- 安全做法是：只用 context 控制超时，把
Client.Timeout设为 0（禁用），并在context.WithTimeout里覆盖全部阶段 - 对流式响应（如
text/event-stream），需额外监听ctx.Done()并主动关闭resp.Body，否则 goroutine 泄漏 - 注意
http.Transport.IdleConnTimeout和KeepAlive也会影响重试时的连接复用行为，不是超时问题但常被误判
