推荐用结构体封装重试逻辑：RetryConfig 控制行为，Do 方法执行任务，支持 context 取消、错误分类重试与回调钩子；异步重试需确保所有阻塞操作受 context 约束，避免 goroutine 泄漏。
重试逻辑该封装成函数还是结构体
Go 里任务重试不是“写个 for 循环加 time.Sleep”就完事的。关键在可复用、可取消、可观察。直接裸写循环会把重试策略（指数退避、最大次数、错误过滤）和业务逻辑耦合死，后续加监控或换策略就得改业务代码。
推荐用结构体封装：RetryConfig 控制行为，Do 方法执行任务。这样能自然支持 context 取消、错误分类重试（比如只对 net.OpError 重试）、回调钩子（如每次失败打日志）。
-
MaxAttempts默认设为 3，设 0 表示无限重试（慎用） -
BackoffFunc接收尝试次数，返回time.Duration，别硬编码time.Second * 2，留出定制空间 - 必须接收
context.Context参数，否则 goroutine 泄漏风险极高
用 channel + goroutine 实现异步重试时怎么避免泄漏
常见错误是起 goroutine 后不等它结束，或者没监听 ctx.Done() 就阻塞在 channel 上。一旦父 context 被 cancel，goroutine 还在 sleep 或等待 channel，就成了僵尸协程。
核心原则：所有阻塞操作必须受 context 约束。sleep 不能用 time.Sleep，得用 time.AfterFunc 配合 select；channel 操作必须和 ctx.Done() 同级 select。
立即学习“go语言免费学习笔记（深入）”；
func asyncRetry(ctx context.Context, task func() error, cfg RetryConfig) <-chan error {
ch := make(chan error, 1)
go func() {
defer close(ch)
var err error
for i := 0; i < cfg.MaxAttempts; i++ {
err = task()
if err == nil {
ch <- nil
return
}
if !shouldRetry(err) {
ch <- err
return
}
// 等待退避时间，但可被 ctx 中断
select {
case <-time.After(cfg.BackoffFunc(i)):
case <-ctx.Done():
ch <- ctx.Err()
return
}
}
ch <- err
}()
return ch
}为什么不要在重试函数里直接启动 goroutine 处理结果
很多初学者想“重试失败就丢进 goroutine 异步告警”，结果在 Do 方法里起 goroutine 打日志或发消息——这会导致调用方完全不知道重试是否真正结束，也无法做超时控制或资源清理。
正确做法是让重试本身同步完成，结果由调用方决定如何处理：
- 成功：调用方继续后续流程
- 失败：调用方再决定是否发告警、存 DB 或丢进另一个 worker queue
- 需要异步通知？用 channel 返回结果，由外部 select 处理，而不是在重试内部起 goroutine
否则你会遇到：重试函数返回了，但 goroutine 还在跑，panic 时 panic 日志都来不及打。
context.WithTimeout 和 time.After 的混用陷阱
有人喜欢在重试循环里每轮都新建 context.WithTimeout(ctx, cfg.Timeout)，看起来合理，实则危险。如果任务本身没响应，每个 timeout 都会生成一个新 goroutine 等待超时，协程数随重试次数线性增长。
更稳妥的方式是复用同一个 context，靠外层统一控制生命周期：
- 用
context.WithTimeout(parentCtx, totalTimeout)包住整个重试过程 - 内部 sleep 用
select+time.After，不依赖子 context - 避免在循环内反复调用
context.WithCancel或WithTimeout
退避时间和总超时是两个维度：前者控制节奏，后者控制兜底。混在一起会丢失重试意图——比如总超时 5 秒，但退避到第 3 次已耗尽，后面几次就变成“立刻失败”，失去重试价值。
