重试逻辑必须基于 context.context 实现并发控制与超时管理，禁用死循环+time.sleep；需分层设置 http 单次超时、指数退避（上限 5–10 秒）、错误类型过滤；结果收集推荐 buffered chan result + select 首个成功，避免 waitgroup 阻塞。
重试逻辑不能直接套用 for 循环加 time.Sleep
常见错误是写一个死循环，在每次失败后 time.Sleep 然后重试，这会阻塞 goroutine、浪费资源，且无法控制最大并发数或总超时。真正的并发重试必须和上下文生命周期绑定。
- 所有重试请求必须基于
context.Context，用ctx, cancel := context.WithTimeout(parentCtx, totalTimeout)统一管控整体生命周期 - 每次重试前检查
ctx.Err() != nil，一旦超时或取消立即退出，不发起新请求 - 避免在重试中用
time.Sleep主动挂起，改用select等待ctx.Done()或带超时的time.After - 指数退避建议用
time.Duration(math.Pow(2, float64(attempt))) * time.Second，但上限设为 5–10 秒，防止单次等待过长
http.Client 的 Timeout 和重试要分层控制
很多人把重试逻辑塞进 http.Client.Timeout，这是错的：该字段只控制单次请求的连接+读写总耗时，无法覆盖重试间隔、总耗时或失败判定逻辑。
- 单次请求超时应设得较短（如
5 * time.Second），由http.Client自身保障不卡死 - 重试次数、退避策略、错误类型过滤（如只重试
net.OpError或 5xx，跳过 4xx）必须在业务层判断，不能依赖 HTTP 状态码自动重试 - 务必检查
resp != nil && resp.Body != nil再调用resp.Body.Close()，否则 goroutine 泄漏风险极高 - 若用
http.Transport，记得设置MaxIdleConns和MaxIdleConnsPerHost，否则高并发重试可能触发"too many open files"
用 sync.WaitGroup + chan error 收集结果容易丢错误
并发请求重试常需要知道“是否全部失败”或“首次成功结果”，但直接用 WaitGroup 等待所有 goroutine 结束再汇总，会导致无法及时返回成功响应，也难以中断后续重试。
- 推荐用带缓冲的
chan Result（type Result struct { Data interface{}; Err error }），每个 goroutine 成功/失败都发一次，主 goroutineselect接收首个非错误结果并cancel() - 缓冲区大小设为 1 即可，避免内存堆积；同时用
default分支防阻塞 - 不要在 goroutine 内部 recover panic，HTTP 请求本身一般不会 panic，真正要处理的是
err != nil场景 - 如果必须等全部完成，用
errgroup.Group（需golang.org/x/sync/errgroup），它天然支持 context 取消和错误传播
第三方库如 backoff 不是万能的，关键路径别黑盒依赖
github.com/cenkalti/backoff/v4 能简化退避逻辑，但它不处理 HTTP 请求本身、不集成 context 超时链路、也不区分错误类型——这些仍需你手写判断。
立即学习“go语言免费学习笔记（深入）”；
- 仅用它生成下次等待时长：
next := bo.NextBackOff()，然后自己做select { case - 别用
backoff.Retry包裹整个 HTTP 调用，它会隐藏底层错误细节，导致 401 或 429 被误重试 - 自定义
backoff.BackOff实现时，注意Reset()必须在每次新任务开始前调用，否则退避状态跨请求污染 - 生产环境建议对重试行为打日志，至少记录
attempt=1, url=/api/x, status=0, err="context deadline exceeded"，否则故障时无法区分是网络问题还是退避策略失效
实际最难的不是写重试，是决定“什么时候不该重试”——比如鉴权失败、参数校验不通过、幂等性被破坏的场景，重试只会放大问题。
