闭包捕获变量引用而非值，执行时机由调用决定；循环中闭包共享迭代变量地址，导致全部返回最后一次值。
闭包如何捕获变量并推迟计算
Go 中的闭包不是“延迟求值”的语法糖，它只是捕获周围作用域的变量引用，执行时机完全取决于你何时调用返回的函数。关键在于：闭包本身不自动延迟，func() int 这类签名才表明“准备好了但还没算”。常见错误是误以为赋值给变量就触发了计算，其实只是绑定了逻辑。
典型场景是配置加载、资源预检、或避免在初始化阶段做高开销操作。比如你有一组依赖环境变量的数据库连接参数，不想在 init() 里直接解析失败，而是留到第一次调用时再检查：
func makeDBPortGetter() func() int {
portStr := os.Getenv("DB_PORT")
return func() int {
if portStr == "" {
return 5432 // fallback
}
if p, err := strconv.Atoi(portStr); err == nil {
return p
}
return 5432
}
}
getPort := makeDBPortGetter() // 此时没读环境变量，也没报错
actualPort := getPort() // 这里才真正执行解析逻辑
注意循环中闭包捕获的是变量地址而非值
这是 Go 闭包最常踩的坑：在 for 循环里创建多个闭包，它们共享同一个迭代变量，导致所有闭包最终看到的是最后一次迭代的值。
- 错误写法（所有闭包都返回
3）：funcs := []func() int{} for i := 0; i - 正确写法（传参绑定当前值）：
funcs := []func() int{} for i := 0; i - 或者显式传入参数：
makeFunc := func(val int) func() int { return func() int { return val } } for i := 0; i
闭包延迟求值与性能/副作用的关系
闭包封装的逻辑会在每次调用时重新执行，所以它不适合缓存结果——除非你手动加一层记忆化。如果内部有 I/O、网络请求或复杂计算，重复调用会带来明显开销。
常见做法是组合闭包与 sync.Once 实现“首次调用才执行 + 后续直接返回”：
func makeExpensiveLoader() func() string {
var result string
var once sync.Once
return func() string {
once.Do(func() {
result = loadFromRemote() // 只执行一次
})
return result
}
}
注意：sync.Once 不解决并发安全的“读”，只保证“写”一次；返回的 result 是纯值，无需额外同步。
另外，闭包内若引用大对象（如整个结构体、切片），且该闭包长期存活（比如注册为 HTTP handler），会造成内存无法释放——因为闭包持有了对外部变量的引用，GC 不能回收。
闭包延迟求值在测试和 mock 中的实际用途
单元测试中，你经常需要控制某段逻辑是否执行、何时执行、或返回什么。闭包让这种控制变得自然：把待测行为包装成 func()，测试时可传入 stub 或 spy 函数。
例如一个服务启动函数，依赖某个健康检查：
func StartService(healthCheck func() error) error {
if err := healthCheck(); err != nil {
return err
}
// 启动逻辑...
return nil
}
测试时可以这样写：
// 模拟失败
err := StartService(func() error { return errors.New("down") })
// 模拟成功
err := StartService(func() error { return nil })
// 甚至记录调用次数
var callCount int
err := StartService(func() error {
callCount++
return nil
})
这种模式比全局变量或接口注入更轻量，尤其适合单函数职责清晰的小型模块。
真正容易被忽略的是闭包的生命周期管理：一旦你把闭包传给 goroutine、HTTP handler 或定时器，就要确认它引用的外部变量是否还有效——比如在函数返回后，闭包仍持有局部切片的指针，而该切片已被 GC 回收（虽然 Go 的逃逸分析通常会把它分配到堆上，但并非绝对）。别只盯着“能跑”，得想清楚“能跑多久”。
