HTTP请求需同时检查err和resp.StatusCode，4xx不重试、5xx才重试；用context.WithTimeout替代Client.Timeout；重试应支持jitter和Retry-After；务必正确处理resp.Body读取与关闭。
HTTP请求失败时，resp 为 nil，但 err 不一定代表网络失败
Go 的 http.DefaultClient.Do() 在底层连接失败（如 DNS 解析失败、拒绝连接）时会返回非 nil 的 err，此时 resp 为 nil；但若请求发出去了、服务端返回了 4xx/5xx 状态码，err 可能是 nil，而 resp.StatusCode 已经是错误状态。很多人只检查 err != nil 就认为“调用成功”，结果把 502 当作正常响应处理。
- 必须同时检查
err和resp.StatusCode：先确认err == nil，再判断resp.StatusCode >= 400 - 对 4xx 错误（如
401 Unauthorized、404 Not Found），通常不应重试；5xx（如500、503）才考虑重试 - 用
http.Client的CheckRedirect字段显式禁用重定向，避免因跳转掩盖原始错误状态
用 context.WithTimeout 控制单次请求超时，别依赖 http.Client.Timeout
http.Client.Timeout 是“整个请求生命周期”的上限，包括 DNS 解析、连接、写请求体、读响应头+体——但它无法中断已进入读响应体阶段的阻塞操作（尤其当服务端流式返回且不关闭连接时）。更可靠的方式是用 context 显式控制。
- 每次调用前创建带超时的 context：
ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second) - 传入
req.WithContext(ctx)，而非直接复用全局 client 的固定 timeout - 记得
defer cancel()，否则可能泄漏 goroutine - 超时触发时，
err通常是context.DeadlineExceeded或context.Canceled，需单独识别并归类为临时错误
实现指数退避重试时，避免用 time.Sleep 硬等待
简单 for 循环 + time.Sleep 会阻塞当前 goroutine，且无法响应取消信号。重试逻辑应与 context 生命周期对齐，并支持 jitter 防止雪崩。
- 用
backoff.Retry（来自github.com/cenkalti/backoff/v4）或手写带 jitter 的退避：每次休眠时间 =base * 2^attempt + rand(0, base) - 每次重试前检查
ctx.Err() != nil，及时退出 - 对 429（Too Many Requests）响应，应解析
Retry-Afterheader 并优先使用它，而不是套用通用退避 - 重试次数建议设为 3～5 次，超过后直接返回原始错误，避免拖长用户等待
解析 JSON 响应前，先确认 resp.Body 可读且未关闭
常见错误是忽略 resp.Body 的状态：如果上层已调用 resp.Body.Close()（比如在中间件里提前读取了 body），后续再 json.NewDecoder(resp.Body).Decode() 就会报 invalid character 'x' looking for beginning of value 或 EOF。
立即学习“go语言免费学习笔记（深入）”；
- 始终在 defer 中关闭
resp.Body，但要在读取完响应后才 close - 对非 2xx 响应，也应读取并丢弃
resp.Body（例如用io.Copy(io.Discard, resp.Body)），否则连接可能无法复用 - 用
bytes.Buffer先读全 body 再解析，方便日志记录和多次解码（如先看error字段再决定是否解析 data） - 注意
Content-Encoding: gzip场景：默认http.Client会自动解压，但若手动读 body，需确保未跳过resp.Header.Get("Content-Encoding")判断
重试机制真正难的不是代码行数，而是区分哪些错误该重试、哪些该立刻上报、哪些要降级；还有就是 Body 读取时机和连接复用之间的隐式耦合——这两点在线上出问题时最难定位。
