不能用全局变量或参数传retryCount，因为参数传递易漏传错传，全局变量在并发下会竞态；闭包可私有化绑定状态，确保各goroutine互不干扰。
为什么不能用全局变量或参数传 retryCount
在 Go 的并发请求场景里，比如调用第三方 API 时做指数退避重试，很多人第一反应是把 retryCount 放到函数参数里，或者用包级变量存。前者会让每个调用都得手动维护计数，极易漏传、错传；后者在并发下直接竞态——两个 goroutine 同时读写同一个 retryCount 变量，结果不可预测。
闭包的天然优势就在这：它把状态“私有化”绑定到每次调用生成的函数实例上，互不干扰。
如何用闭包封装 retryCount 和 backoffDuration
核心是让闭包捕获并更新自己的状态变量，同时返回一个可重复调用的函数。典型结构如下：
func newRetryFunc(maxRetries int) func() (time.Duration, bool) {
var count int
return func() (time.Duration, bool) {
if count >= maxRetries {
return 0, false
}
// 指数退避：2^count * 100ms
duration := time.Duration(1<<count) * 100 * time.Millisecond
count++
return duration, true
}
}使用时每个 goroutine 拿到独立的闭包实例：retry := newRetryFunc(3)，后续每次调用 retry() 都会更新它自己的 count，安全又清晰。
闭包状态和 context.WithTimeout 组合时的常见陷阱
很多人想把重试逻辑和超时控制一起塞进一个函数里，结果发现 context.WithTimeout 创建的 deadline 是固定的，而重试是逐步推进的——如果在闭包里提前创建了带 timeout 的 context，那第一次失败后 sleep 再重试时，context 可能已经过期了。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：每次重试前才新建
context.WithTimeout(ctx, timeout)，而不是在闭包初始化时创建 - 不要把
context.Context存在闭包变量里，它不是线程安全的，且生命周期与重试节奏不匹配 - 如果需要传递 cancel 函数，只在当前重试轮次内调用
cancel()，别跨轮次复用
性能与逃逸：闭包捕获大对象时要注意什么
闭包捕获的变量如果体积大（比如一个未序列化的 struct 或 map），会导致堆上分配，GC 压力上升。更隐蔽的问题是：哪怕你只捕获一个 int，但如果闭包被返回并长期存活（比如注册为回调），Go 编译器可能把整个栈帧抬升到堆上。
实操建议：
- 只捕获真正需要的状态变量，避免捕获整个
struct，优先拆出字段如retryCount、baseDelay - 用
go tool compile -gcflags="-m"检查是否发生逃逸，尤其关注闭包返回值是否标注leak - 如果重试逻辑极简单（如固定次数+固定间隔），考虑不用闭包，直接用 for 循环 + 局部变量，更轻量
闭包本身不重，但状态绑定和生命周期管理容易松动——重点不是“怎么写闭包”，而是“谁持有状态、何时释放、会不会意外共享”。
