必须为每个任务创建独立带超时的context，并用backoff.WithContext包装退避实例；并发任务需隔离退避状态，每次新建或重置backoff实例；仅对临时性错误（如5xx、429）重试，非幂等请求默认不重试；重试前重建http.Request，结合信号量限流防重试风暴。
用 backoff.Retry + context.WithTimeout 控制单任务重试生命周期
每个任务必须绑定独立的 context.Context，且带明确超时（如 context.WithTimeout(ctx, 30*time.Second)）。不能复用外层 long-lived ctx，否则重试会继承上游过长 deadline；也不能用 context.Background()，否则无法响应取消。关键点在于：backoff.Retry 本身不感知 ctx 超时，必须用 backoff.WithContext(bo, ctx) 包装退避实例——否则哪怕第 5 次重试前 ctx 已 cancel，它仍会 sleep 并执行。
并发任务间退避状态必须隔离，别共享 backoff.BackOff 实例
多个 goroutine 共用同一个 backoff.ExponentialBackOff 实例会导致间隔错乱：A 任务第 2 次失败后拿到 400ms 间隔，B 任务紧接着调 NextBackOff() 却拿到第 3 次的 800ms，完全失序。正确做法是：
- 每次任务启动时新建实例：
bo := backoff.NewExponentialBackOff() - 或复用前显式调
bo.Reset() - 设抖动：
bo = backoff.WithJitter(bo)，避免“重试风暴” - 调大上限：
bo.MaxInterval = 5 * time.Second，默认 1s 太小，高延迟下游撑不住
只对临时性错误重试，HTTP 场景下需同时检查 error 和 StatusCode
盲目重试会放大错误。必须收口统一判断逻辑，例如：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 网络层：
errors.Is(err, net.OpError)或err != nil && strings.Contains(err.Error(), "timeout")不可靠，改用netErr, ok := err.(net.Error); ok && netErr.Timeout() - HTTP 响应层：仅当
resp.StatusCode >= 500 || resp.StatusCode == 429才重试；400、401、404立即失败 - 非幂等请求（如 POST）默认不重试，除非服务端明确支持幂等 token
- 每次重试前重建
*http.Request，尤其 body 需从缓存 bytes 重新构造，因原req.Body已关闭或读尽
结合信号量限流，防止重试放大并发压力
高并发队列里，若每个失败任务都立刻按指数退避发起重试，瞬间可能涌出数千连接打垮下游。必须在外层加信号量节流：
- 用
sem := make(chan struct{}, 20)控制最大并发上传数 - 每个任务 goroutine 启动前先
sem ，完成后 - 重试逻辑放在信号量获取之后，确保重试也受控
- 避免用
time.AfterFunc延迟重试——它会泄漏 goroutine；坚持用backoff.Retry内置循环
重试不是兜底，是针对「瞬态故障」的窄口径补救。参数调得再细，若没做错误分类、没隔离退避状态、没压住并发，再好的指数退避也会变成压垮服务的最后一根稻草。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
