Go中用函数值实现重试装饰器需传入无参函数func() error，通过闭包预绑定参数；避免直接传带参函数、依赖外部变量或在重试中盲目recover panic。
Go 里怎么用函数值实现重试装饰器
Go 没有原生装饰器语法，但可以用函数值（func()）+ 闭包模拟。核心是把原始操作包装成无参函数，再由重试逻辑统一调度执行。
常见错误是直接传带参数的函数，结果编译报错：cannot use xxx (type func(int, string) error) as type func() error。必须提前绑定参数，返回一个 func() error。
- 重试函数接收的是
func() error，不是任意签名的函数 - 参数绑定推荐用闭包，而不是靠外部变量（易被并发修改）
- 不要在重试逻辑里捕获 panic，除非你明确要 recover 并转为 error
示例：
retry := func(f func() error, maxRetries int) error {
var err error
for i := 0; i <= maxRetries; i++ {
err = f()
if err == nil {
return nil
}
if i == maxRetries {
break
}
time.Sleep(time.Second * time.Duration(1<<uint(i))) // 指数退避
}
return err
}
<p>// 正确：提前绑定参数，生成 func() error
err := retry(func() error {
return httpGetWithTimeout("<a href="https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca">https://www.php.cn/link/46b315dd44d174daf5617e22b3ac94ca</a>")
}, 3)
为什么 retry.WithDelay 不该用 time.Sleep 阻塞 goroutine
在 HTTP 客户端、数据库调用等 IO 密集场景，用 time.Sleep 做重试间隔会阻塞当前 goroutine，浪费调度资源。尤其高并发时，大量 goroutine 卡在 sleep，容易拖垮整个服务。
立即学习“go语言免费学习笔记（深入）”；
更合理的做法是用 time.After + select，把等待变成非阻塞的通道操作，让 goroutine 可以被调度器复用。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
time.Sleep是同步阻塞，goroutine 状态为 “waiting”；time.After是异步通知，goroutine 可以在等待期间处理其他任务（如果配合 context 或多路 select） - 如果你用的是第三方库如
github.com/avast/retry-go，它默认就是基于time.After实现的 - 自己写时别漏掉
ctx.Done()检查，否则重试可能无法被 cancel
简化版非阻塞重试片段：
func retryWithContext(ctx context.Context, f func() error, maxRetries int) error {
var err error
for i := 0; i <= maxRetries; i++ {
err = f()
if err == nil {
return nil
}
if i == maxRetries {
break
}
select {
case <-time.After(time.Second * time.Duration(1<<uint(i))):
case <-ctx.Done():
return ctx.Err()
}
}
return err
}
context.WithTimeout 套 retry 时 timeout 到底算谁的
很多人以为给重试函数加了 context.WithTimeout，就等于“整个重试过程不能超时”。其实不是——如果没在每次重试内部也检查 ctx.Err()，那第一次调用卡住 5 秒，重试三次就耗掉 15 秒，远超你设的 10 秒 timeout。
关键点：timeout 必须作用在**每次尝试**上，而不是只包在 retry 外层。
- 外层
context.WithTimeout控制整体生命周期，防止无限 hang - 每次
f()执行前，都应传入该 context，并在 IO 操作中显式使用（比如http.NewRequestWithContext、db.QueryContext） - 如果
f()本身不支持 context（比如老版本库），就得自己做超时封装，例如用chan+select包一层
重试策略里 exponential backoff 的底数和上限怎么定
指数退避不是越“陡”越好。底数选 2 很常见，但实际要看下游服务的恢复节奏：API 突然 503，可能 100ms 就恢复；数据库连接池打满，可能需要秒级冷却。
硬编码 1 容易翻车——第 6 次重试就是 64 秒，用户早关页面了。
- 建议初始延迟用
100 * time.Millisecond，乘数用 2，上限设为5 * time.Second（可配） - 避免用
int位移算时间，改用time.Duration(math.Pow(2, float64(i))) * base更安全（防溢出） - 生产环境务必加 jitter（随机偏移），比如 ±30%，防止大量请求在退避后同一时刻涌向下游
真正难的不是写对逻辑，而是搞清你调用的那个接口——它失败是因为瞬时过载？网络抖动？还是永久性错误（如 404、401）？后者重试毫无意义，反而加重负担。
