Go闭包捕获变量地址而非值快照，多个闭包共享同一内存地址，修改会影响所有闭包；其底层是含函数指针和变量地址列表的funcval结构体。
闭包捕获的是地址，不是值快照
Go 闭包从来不会“复制”变量值，它捕获的是变量在内存中的地址。哪怕 i 是 int，name 是 string，闭包里读写的都是指向它们的指针——你改它，所有共享该变量的闭包下次执行时都会看到新值。
这不是 bug，是设计：Go 编译器把闭包实现为一个真实结构体（funcval），里面存着函数入口指针 + 外部变量地址列表。所以多个闭包实例若捕获同一个 i，它们实际共享同一块内存。
- 常见错误现象：
for i := 0; i 输出全是 <code>3 - 根本原因：循环变量
i在栈上只分配一次，所有 goroutine 闭包都持有&i - 验证方式：加
go build -gcflags="-m"，能看到&i escapes to heap提示
Go 1.22 起循环变量捕获行为变了，但本质没变
Go 1.22 对 for 循环做了优化：每次迭代会为循环变量分配独立栈空间（或堆空间），让每个闭包捕获的是“本轮专属”的地址。看起来像值捕获，实则仍是引用——只是地址不复用了。
这缓解了经典翻车，但没改变底层逻辑：闭包依然靠地址访问变量，依然受逃逸分析支配。旧写法在 1.22 里可能“碰巧”正常，但依赖编译器行为，不可移植。
立即学习“go语言免费学习笔记（深入）”；
- 不要依赖版本差异写法，显式隔离更可靠：
for i := 0; i -
range遍历同理：v是复用变量，必须写成v := v才安全 - defer 中闭包仍按老规则：参数在
defer语句执行时求值，函数体在 return 前执行时读变量
逃逸分析决定变量去哪，闭包只是触发器
闭包本身不强制变量上堆；真正起作用的是逃逸分析。只要编译器发现变量被闭包引用，且该闭包可能存活到外层函数返回之后，就会把变量移到堆上——哪怕只是一个 int。
典型触发场景包括：外层函数返回闭包、闭包存入全局 map、传给 goroutine 或 context.WithValue。一旦逃逸，变量生命周期就和闭包绑定，GC 不会回收它，直到闭包值不再被引用。
- 高频创建闭包（如热循环中调用
makeHandler）会持续分配funcval结构体，增加 GC 压力 - 捕获大对象（如
*bytes.Buffer、map[string][]byte）容易无意拖住大量内存 - 替代思路：优先用参数传值；状态管理改用 struct + 方法，内存布局更可控
defer 和 goroutine 中闭包的求值时机必须分清
defer 和 go 启动闭包时，参数求值和闭包执行是分离的：参数在 defer 或 go 语句执行那一刻就确定了，而闭包体内的自由变量要等到真正运行时才读取。
这个时间差就是坑的来源。比如 defer func() { println(i) }() 里的 i 是 defer 实际执行时的值，不是写这行时的值；而 defer func(x int) { println(x) }(i) 的 x 是注册瞬间就固定的。
- 反模式：
go func() { fmt.Println(i) }()—— 主协程可能已退出，i所在栈帧失效，行为未定义 - 安全写法：
go func(val int) { fmt.Println(val) }(i)或val := i; go func() { fmt.Println(val) }() - 混合陷阱：
defer func(x int) { println(x, i) }(i)——x是注册时值，i是执行时值
go build -gcflags="-m"，比凭经验猜靠谱得多。 
