闭包捕获的是变量地址，不是值；Go闭包绑定外部变量的内存地址而非值快照，导致for循环中所有闭包共享同一地址、最终均输出终值，修复需每次迭代创建新变量（如i := i）或通过参数传值。
闭包捕获的是变量地址，不是值
Go 闭包捕获外部变量时，拿到的是该变量的内存地址，不是创建闭包那一刻的副本。这意味着多个闭包共享同一份内存，后续修改会影响所有闭包行为。
典型翻车场景：
for i := 0; i → 全部输出 <code>3-
defer func() { fmt.Println(i) }(); i = 20→ 输出20，不是注册时的10
原因不是“闭包没捕获”，而是所有匿名函数都读取同一个 i 的地址，而 i 在循环结束或 defer 执行时早已更新。
正确做法：
立即学习“go语言免费学习笔记（深入）”；
- 显式绑定局部变量：
val := i; go func() { fmt.Println(val) }() - 参数传入闭包：
go func(v int) { fmt.Println(v) }(i) - 对结构体字段、切片、map 等引用类型，拷贝变量名也不等于隔离底层数据
闭包是否导致变量逃逸到堆上？
是的，但不是绝对。是否逃逸取决于变量是否“可能被闭包外持有”——编译器通过逃逸分析静态判断。只要闭包被返回、传给 goroutine、赋给全局变量等，它捕获的变量大概率逃逸到堆。
常见逃逸触发点：
- 闭包作为返回值：
func() int { x := 42; return func() int { return x } }→x逃逸 - 闭包传入
go启动：go func() { _ = x }()→x极大概率逃逸 - 闭包赋给 interface{} 参数（如
fmt.Println(func(){})）→ 闭包本身逃逸，连带捕获变量也逃逸
验证方式必须用：go build -gcflags="-m -m"，单个 -m 不显示变量级逃逸信息。
注意：&x escapes to heap 并不等于“一定逃逸”，要看上下文；真正决定逃逸的是“地址是否泄露”，不是取地址动作本身。
逃逸带来的性能影响不只是 GC 压力
堆分配变量会带来三重开销：GC 追踪成本、间接寻址延迟、CPU 缓存局部性下降。
高频场景下差异明显：
- HTTP handler 内每请求生成闭包 → P99 延迟可测性上升
- hot loop 中反复创建闭包 → GC 频次增加，尤其小对象堆积
- 栈上变量连续存放，堆上对象分散 → CPU cache miss 概率升高
更隐蔽的问题：
- 哪怕只捕获结构体一个字段，整个结构体也可能逃逸（Go 当前不支持字段级逃逸分析）
- 使用
-l关闭内联后看到的逃逸路径，和真实上线行为不一致，仅用于调试定位 - 即使 defer 最终没执行（比如被 recover 拦截），逃逸已发生，无法撤回
defer 中闭包捕获变量的时机陷阱
defer 注册时只求值函数参数，闭包体内的变量在真正执行时才读取 —— 这中间存在时间窗口，变量可能已被修改。
错误写法：
-
i := 10; defer func() { fmt.Println(i) }(); i = 20→ 输出20 -
for _, v := range items { defer func() { log.Print(v.name) }() }→ 全部打印最后一个v的字段
安全写法：
- 显式快照：
val := i; defer func() { fmt.Println(val) }() - 参数传入：
defer func(x int) { fmt.Println(x) }(i) - recover() 必须直调：
defer func() { if r := recover(); r != nil { ... } }()，不能套一层闭包再 recover
最易被忽略的一点：range 循环中 v 是复用变量，它的地址在整个循环里不变，闭包捕获的是这个固定地址，不是每次迭代的新值。
