context.WithTimeout仅控制单次执行时限，不自动重试；重试需外层手动循环+错误判断，且每次重试必须新建context，推荐用for+select配合指数退避实现。
context.WithTimeout 本身不重试，只控制单次执行时限
很多人以为 context.WithTimeout 能自动重试，其实它只是给一次调用加个“死线”——超时就取消，不会多跑第二遍。真正重试得靠外层逻辑手动循环+判断错误类型。
常见错误现象：context.DeadlineExceeded 报出来就 panic 或直接返回，没做重试兜底；或者把重试逻辑写在 select 里，结果 timeout 后 goroutine 还在跑，泄漏资源。
- 使用场景：HTTP 请求、RPC 调用、数据库查询等外部依赖操作
- 关键点：每次重试必须新建
context，不能复用已 cancel 的 context - 别在重试循环里用同一个
ctx，否则第二次进来的ctx.Err()已是context.Canceled
用 for + select 实现带退避的重试
最轻量也最可控的方式是手写循环，配合 time.Sleep 控制间隔。重点不是“怎么循环”，而是“什么时候停”和“怎么避免雪崩”。
示例中用的是固定间隔，但生产环境建议用指数退避（如 100ms → 200ms → 400ms）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
for i := 0; i
-
cancel()必须显式调用，尤其在循环内，否则 context 泄漏 - 判断错误要用
errors.Is(err, context.DeadlineExceeded)，别用==，因为底层可能是 wrapped error - 别在重试前无脑 sleep，先检查
ctx.Err()是否已触发，避免无效等待
用 backoff 库简化重试策略（推荐生产用）
自己算退避时间、控制最大重试次数、处理 jitter 容易出错。直接用 github.com/cenkalti/backoff/v4 更稳。
它把重试逻辑和策略解耦了，你只管写业务函数，它负责调度：
operation := func() error {
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()
return doSomething(ctx)
}
err := backoff.Retry(operation, backoff.WithContext(backoff.NewExponentialBackOff(), ctx))
-
backoff.NewExponentialBackOff()默认起始 100ms，最大 10s，带 jitter，不用自己算 - 务必套一层
backoff.WithContext，否则 cancel 信号传不到重试内部 - 注意：该库的
Retry不会自动捕获context.Canceled，你仍需在operation里检查ctx.Err()并返回对应 error
超时重试组合时最容易漏掉的三个点
不是代码写不出来，而是上线后才发现某些 case 没覆盖到：
- 外层 context（比如 HTTP handler 的
r.Context()）超时了，但重试还在继续 —— 必须把外层 ctx 传进重试逻辑，并在每次 retry 前检查ctx.Err() != nil - 重试过程中，原始请求的 body（比如
*bytes.Reader）可能已被读过一遍，第二次重试会读空 —— 要确保可重放，例如用io.NopCloser(bytes.NewReader(data))包装 - 并发重试多个请求时，共享的
http.Client如果没设Timeout，单个 request 超时不影响 client 级别的连接复用，但可能拖慢整个连接池 —— 建议 client 也设Timeout，且比单次 retry timeout 略长
超时和重试不是开关一开就完事，它们嵌套起来之后，哪个 ctx 控制哪段生命周期、哪次错误该重试哪次该熔断，边界很容易模糊。多打几行日志，尤其是每次 retry 前后打印 ctx.Err() 和 error 类型，比猜强得多。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
