最简重试逻辑需用 net/http + time.Sleep 实现：捕获超时、连接类错误重试，4xx 错误不重试；用 context.WithTimeout 控制单次超时；每次重试前 sleep 并指数退避；每次新建 *http.Request。
用 net/http + time.Sleep 实现最简重试逻辑
Go 标准库不自带 HTTP 重试，得自己套一层循环。核心是捕获 error 并判断是否值得重试，而不是无脑重试所有失败。
常见错误现象：Get "https://api.example.com": context deadline exceeded、connection refused、Client.Timeout exceeded —— 这些适合重试；而 401 Unauthorized 或 404 Not Found 一般不该重试。
- 用
context.WithTimeout控制单次请求超时，别依赖http.Client.Timeout全局设死 - 重试前必须
time.Sleep，否则可能瞬间打爆下游；推荐从 100ms 开始指数退避（如 100ms → 200ms → 400ms） - 别在循环里复用同一个
*http.Request：它内部带 body 和 context，第二次调用会报http: Request.Body is nil
示例关键片段：
for i := 0; i < maxRetries; i++ {
req, _ := http.NewRequestWithContext(ctx, "GET", url, nil)
resp, err := client.Do(req)
if err == nil && resp.StatusCode < 500 {
return resp, nil
}
if i < maxRetries-1 {
time.Sleep(time.Duration(100*math.Pow(2, float64(i))) * time.Millisecond)
}
}封装成可复用的 RetryClient 类型时要注意什么
直接写函数也能用，但多人协作或项目变大后，封装成结构体更可控。重点不是“怎么定义 struct”，而是字段设计是否暴露了不该暴露的细节。
立即学习“go语言免费学习笔记（深入）”；
使用场景：需要统一控制重试次数、退避策略、错误过滤规则，且不同 API 调用需差异化配置（比如文件上传不重试 500，但查询接口要重试）。
-
MaxRetries建议设为 3～5，默认 3；设太大容易掩盖真实故障 - 别把
http.Client嵌入结构体并导出——外部修改其Transport或Timeout会破坏重试语义；应该只暴露Do()方法 - 加一个
ShouldRetry函数字段，类型为func(*http.Response, error) bool，比硬编码判断更灵活 - 避免在
Do()内部 newhttp.Client：连接复用失效，CPU 和 fd 消耗陡增
为什么不用第三方库如 backoff 或 retryablehttp
这些库功能全，但引入后常带来两个隐性成本：依赖版本冲突、默认行为不符合业务预期（比如自动重试 5xx 且不区分 500/503）。
性能影响：标准库 net/http 已经足够快，第三方封装如果在每次重试都新建 http.Client 或滥用 sync.Pool，反而降低吞吐。
-
backoff.Retry默认用ExponentialBackOff，但它的初始间隔是 100ms，最大间隔 1s —— 对内网服务可能太保守，对海外 API 又可能太激进 -
retryablehttp的CheckRetry回调接收*http.Response，但首次请求失败时resp是nil，容易 panic，得手动判空 - 如果你只需要「失败后等 200ms 再试一次」，写 10 行代码比配 5 个回调更可靠
重试时最容易被忽略的副作用
HTTP 方法语义不是装饰：对 POST / PUT / DELETE 盲目重试，可能造成重复下单、库存扣双倍、资源删两次。
兼容性影响：有些老服务不支持 idempotency-key 头，也没实现幂等逻辑，此时重试等于制造数据异常。
- GET / HEAD 请求天然幂等，可放心重试；其他方法必须先确认服务端是否支持幂等（看文档或加
X-Idempotency-Key） - 如果请求带 body（如 JSON），重试前要确保
req.Body可重读 —— 用bytes.NewReader包一层原始数据，别传strings.NewReader后反复用 - 日志里务必打出重试次数和原始错误，否则线上出问题时分不清是第几次失败，还是根本没走重试逻辑
真正难的从来不是“怎么加重试”，而是“哪些请求能重试、重试几次、等多久、失败后怎么兜底”。这些决策没法靠工具自动做，得贴着业务逻辑写。
