闭包捕获的是变量的引用而非值，多个闭包共享同一变量地址，导致for循环中所有闭包输出相同最终值；修复方法是用局部变量拷贝或通过函数参数传值。
闭包捕获的是变量的引用，不是值
Go 里闭包捕获外部变量时，捕获的是该变量在栈/堆上的内存地址，而不是创建闭包那一刻的副本。这意味着多个闭包共享同一份变量，修改会相互影响。
常见错误现象：for 循环中直接用循环变量构造闭包，结果所有闭包都打印最后一个值。
- 典型场景：启动多个
goroutine，每个都用i做参数，但全输出len(slice)-1 - 根本原因：循环变量
i是单个变量，每次迭代只是改它的值，闭包都闭包了同一个&i - 修复方式：在循环体内用局部变量拷贝，比如
idx := i，再闭包idx - 或者用函数参数传入：将
go func(n int) { ... }(i)作为立即执行模式
示例：
for i := 0; i < 3; i++ {
go func() {
fmt.Println(i) // 全部输出 3
}()
}
// ✅ 正确写法：
for i := 0; i < 3; i++ {
i := i // 创建新绑定
go func() {
fmt.Println(i) // 输出 0, 1, 2
}()
}
闭包变量逃逸到堆上会影响性能
当一个局部变量被闭包捕获，且该闭包生命周期超出当前函数作用域（比如返回出去、传给 goroutine），Go 编译器会把它从栈移到堆——这就是逃逸分析触发的堆分配。
立即学习“go语言免费学习笔记（深入）”；
使用场景：返回闭包的工厂函数、注册回调、延迟执行逻辑。
- 判断是否逃逸：用
go build -gcflags="-m"查看变量是否标注moved to heap - 影响：堆分配 + GC 压力；对高频调用路径（如 HTTP 中间件）尤其敏感
- 优化思路：避免在热路径返回闭包；能用结构体字段替代闭包捕获的，优先用结构体
- 注意：哪怕只捕获一个
int，只要闭包外泄，整个变量都会逃逸
defer 中的闭包捕获时机容易误解
defer 语句注册闭包时，**参数表达式立即求值，但闭包体延迟执行**。这和普通闭包不同，需要分两层理解。
常见错误现象：以为 defer func(x int) { fmt.Println(x) }(i) 会打印最终的 i，其实它打印的是 defer 执行那一刻的 i 值——而 defer 的参数是注册时就确定的。
- 关键点：
defer func(x int) { ... }(i)中的i是「传值」，不是闭包捕获 - 如果写成
defer func() { fmt.Println(i) }()，才是闭包捕获，此时打印的是函数返回前的i - 混合写法陷阱：
defer func(x int) { fmt.Println(x, i) }(i)——x是注册时值，i是执行时值 - 建议：统一用显式参数传值，避免混用，可读性高且行为确定
方法值（method value）本质也是闭包
当你写 obj.Method（不带括号），得到的是一个方法值，它隐式捕获了接收者 obj 的副本或地址，行为上等价于闭包。
使用场景：把方法当回调传给 sort.SliceStable、http.HandlerFunc 等接受函数值的接口。
- 如果接收者是值类型，方法值捕获的是该值的拷贝；指针类型则捕获指针
- 注意别意外触发复制：大结构体做值接收者 + 频繁生成方法值 → 内存和性能开销
- 和普通闭包一样，方法值也会导致逃逸：若
obj是局部变量且方法值外泄，obj通常逃逸 - 验证方式：对方法值变量名加
-gcflags="-m"，看是否提示escapes to heap
闭包看着简单，但变量生命周期、求值时机、逃逸路径这三块叠在一起，稍不注意就会产出难复现的并发 bug 或静默性能劣化。
