go闭包捕获变量地址而非值快照，导致多个闭包共享同一存储空间；典型bug出现在for循环中，若匿名函数引用循环变量i且逃逸出作用域，所有闭包将共享最后的i值。
Go 闭包不是靠特殊语法“实现”的，而是当匿名函数满足两个条件时自然形成的行为：引用外层局部变量 + 该函数逃逸出定义作用域（比如被返回、存入切片、传给 goroutine）。没逃逸、没引用，就只是个普通匿名函数。
闭包捕获的是变量地址，不是值快照
这是绝大多数闭包 bug 的根源。Go 闭包捕获的是变量在内存中的地址，所有闭包共享同一份存储空间。
- 现象：
for i := 0; i 最终输出 <code>3 3 3 - 原因：循环变量
i在栈上只有一份，每次迭代只是改它的值；所有闭包都读取同一个地址 - 修复本质不是“加括号”，而是切断共享：用
val := i声明新绑定，或 Go 1.22+ 中直接写for i := range items { ... }（此时每次迭代的i是独立绑定） - 注意：即使
i是int这种小类型，只要被闭包捕获且逃逸，它就会被分配到堆上（go build -gcflags="-m"可验证）
goroutine 中闭包传参必须显式传值
在 go 关键字后直接启动未带参闭包，极大概率导致读到错误或已失效的变量值。
- 反模式：
go func() { fmt.Println(i) }()—— 主协程可能早已退出，i所在栈帧被复用，甚至触发未定义行为 - 正确写法：
go func(id int) { fmt.Println(id) }(i)—— 参数在go语句执行时求值，闭包体内访问的是副本 - 若闭包需访问多个变量，建议打包成结构体传参，避免参数列表过长或遗漏
- 特别注意：如果闭包内还要调用其他函数并传入这些变量，别忘了它们也得是传进来的副本，而不是又去捕获外部变量
闭包作为返回值会触发变量逃逸
一旦闭包被返回、赋值给全局变量、塞进切片或 map，它捕获的所有变量都会被迫分配到堆上。
- 影响：小变量（如
int）堆分配开销不大，但若闭包捕获了大结构体或切片，会显著增加 GC 压力 - 验证方式：
go build -gcflags="-m" main.go，关注类似./main.go:5:6: moved to heap: count的提示 - 优化思路：只捕获真正需要的变量；避免在工厂函数中无意捕获大对象指针；必要时用结构体替代闭包来显式控制内存布局
- 典型陷阱：
func() []func() { var res []func(); for i := range xs { res = append(res, func() { println(i) }) }; return res }—— 整个res切片和其中每个闭包都会逃逸
真正难调试的从来不是“怎么写闭包”，而是“这个 i 到底是谁的、什么时候变的、还有谁在读它”——尤其当它同时出现在 defer、goroutine 和切片里时，地址复用和求值时机的叠加会让问题变得隐蔽。别依赖直觉，用 -gcflags="-m" 看逃逸，用 val := i 断共享，比反复加日志更可靠。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
