闭包捕获的是变量地址而非值拷贝，底层为函数指针加外部变量指针的结构体，多个闭包共享同一内存；典型现象是for循环中所有闭包输出终值。
闭包捕获的是变量地址，不是值拷贝
Go 闭包在底层是函数指针 + 指向外部变量的指针组成的结构体。这意味着所有共享同一外部变量的闭包，读写的是同一块内存。
典型现象：for i := 0; i 最终输出 <code>3 3 3，而非 0 1 2。
- 根本原因：循环变量
i在栈上只分配一次，每次迭代只是改写其值；所有闭包都持有&i - 修复方式一（推荐）：在循环体内用新变量隔离
v := i，再让闭包捕获v - 修复方式二：把
i作为参数传给闭包，func(val int) { fmt.Print(val) }(i) - 注意：即使
i是int这类值类型，Go 依然按地址捕获——除非显式复制或传参
defer 和 goroutine 中闭包的求值时机差异
defer 和 go 启动闭包时，参数求值和闭包体执行是分离的：参数在 defer 或 go 语句执行时求值（即“定义时”），而闭包体在真正触发时才运行（即“执行时”）。
常见错误：defer func() { println(i) }() 中，i 的值取决于 defer 实际执行时的状态，不是写这行时的值。
立即学习“go语言免费学习笔记（深入）”；
-
defer func(val int) { println(val) }(i)✅ 参数val在defer注册瞬间就确定了 -
go func(id int) { fmt.Println(id) }(i)✅ 避免 goroutine 启动后i已被修改或栈回收 - 反模式：
go func() { fmt.Println(i) }()❌ 主协程可能很快退出，i所在栈帧失效，行为未定义 - 尤其要注意：goroutine 中若闭包引用了短生命周期局部变量（如函数内临时切片），且逃逸分析未触发堆分配，极易 crash
闭包逃逸导致堆分配与 GC 压力
只要闭包被捕获的变量“逃逸”出当前栈帧（比如闭包被返回、存入全局变量、塞进切片、传给 context.WithValue 等），编译器就会把该变量从栈移到堆——连带整个闭包上下文一起堆分配。
验证方法：go build -gcflags="-m" main.go，看是否有 escapes to heap 或 moved to heap 提示。
- 一个
int变量被闭包捕获并逃逸，也会触发堆分配，不只是大对象 - 频繁创建逃逸闭包（如在热路径中生成大量
func() error）会增加 GC 频率 - 避免方式：优先用参数传值替代捕获；若需状态，考虑用结构体 + 方法，更可控内存布局
- 注意：
append到切片后存储闭包，哪怕切片是局部变量，也足以触发逃逸
闭包变量生命周期延长带来的隐性依赖
闭包会让它捕获的变量“活”得比外层函数更久——只要闭包还被引用，变量就不会被 GC 回收。这既是特性，也是隐患。
典型问题：闭包捕获了大对象（如 *bytes.Buffer、map[string][]byte）或数据库连接，但闭包本身长期存活（如注册为 HTTP handler、存入全局 map），导致内存无法释放。
- 检查点：闭包是否被赋值给包级变量、塞进
sync.Map、作为回调传给第三方库 - 调试技巧：用
pprof查 heap profile，过滤闭包相关类型名（如closure.*） - 容易被忽略的是：闭包捕获了结构体字段指针，而结构体本身被其他长生命周期对象持有——形成隐性强引用链
- 没有银弹，但加一层显式清理逻辑（如闭包内带
close或reset调用）能缓解
