Go闭包捕获变量的内存地址而非值拷贝，多个闭包共享同一变量实例；for循环中直接使用循环变量创建闭包会导致所有闭包指向最后一次迭代的i值。
闭包捕获的是变量的地址，不是值拷贝
Go 闭包捕获的是外围作用域中变量的内存地址，不是值副本。这意味着多个闭包共享同一变量实例，修改其中一个闭包内通过该变量名所做的变更，会反映在其他闭包里。
常见错误现象：for 循环中直接用循环变量创建闭包，结果所有闭包都指向最后一次迭代的 i 值：
for i := 0; i < 3; i++ {
defer func() { fmt.Println(i) }() // 全部输出 3
}
原因在于：所有匿名函数共享同一个 i 变量的地址，循环结束时 i == 3，闭包执行时读取的就是这个最终值。
- 解决方法：用局部变量显式复制值（
val := i），或把i作为参数传入闭包 - 注意：即使变量是基础类型（如
int、string），闭包捕获的仍是其栈上地址，不是值本身 - 结构体字段、切片头、map 变量等复合类型也一样——闭包拿到的是它们的“头部”地址，而非底层数据拷贝
为什么不能简单说“是引用”或“是值”
Go 没有传统意义上的“引用类型”概念（不像 C++ 的 & 或 Java 的对象引用语义）。闭包捕获行为更接近“变量绑定”，即闭包持有一个指向原始变量存储位置的指针，但语言不暴露该指针本身。
立即学习“go语言免费学习笔记（深入）”；
使用场景差异明显：
- 对
int、struct等值类型变量：你读写的是同一块栈内存，效果类似“引用” - 对
slice、map、chan、func、interface{}：它们本身就是包含指针的头结构，闭包捕获的是这个头结构的地址，因此底层数据自然可被共享和修改 - 对
*T类型指针变量：闭包捕获的是指针变量本身的地址，不是它指向的堆内存地址；但间接访问仍能改堆上内容
性能影响很小——闭包只额外保存几个字长的地址，没有深拷贝开销；兼容性无问题，这是 Go 自 1.0 起稳定的行为。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
容易踩的坑：循环 + 闭包 + goroutine
这是最典型的陷阱组合，错误比单纯 defer 更隐蔽，因为并发放大了竞态表现：
for i := 0; i < 3; i++ {
go func() { fmt.Println(i) }() // 输出可能是 3, 3, 3 或乱序，但几乎不会是 0, 1, 2
}
根本原因没变：所有 goroutine 共享同一个 i 地址。但由于调度不可控，你甚至可能看到部分 goroutine 读到中间值（比如 i==1 时被调度），但这只是竞态下的偶然，不是保证行为。
- 正确写法：立即传参
go func(val int) { fmt.Println(val) }(i) - 或者在循环体内定义新变量
val := i，再在闭包中用val - 不要依赖
time.Sleep来“修复”——这只是掩盖竞态，不是解决
闭包捕获与逃逸分析的关系
如果一个变量被闭包捕获，它大概率会从栈逃逸到堆——因为闭包可能比外围函数生命周期更长，Go 编译器必须确保该变量内存持续有效。
你可以用 go build -gcflags="-m" 验证：
func makeAdder(x int) func(int) int {
return func(y int) int { return x + y }
}
这里 x 会被标记为 move to heap，因为它被返回的闭包捕获并可能在 makeAdder 返回后继续使用。
- 逃逸不等于“分配在堆上就慢”——现代 Go 堆分配极快，且有 GC 优化
- 但若高频创建闭包并捕获大结构体，可能增加 GC 压力，此时应考虑重构为传参或复用对象
- 闭包捕获的变量是否逃逸，取决于它的使用方式，而不是类型大小；哪怕只捕获一个
int，只要闭包逃逸，它就得跟着上堆
真正复杂的地方在于：你没法靠看代码直观判断某个变量会不会逃逸，得依赖工具；而一旦它逃逸，你就得意识到——那个变量的生命期已脱离原始作用域，且所有闭包对它的读写都是直接内存操作，没有中间层缓冲或拷贝保护。
