go闭包捕获变量引用而非值，导致循环、defer等场景易出错；正确做法是显式传参或局部拷贝；逃逸分析影响性能；方法值捕获receiver需注意值/指针语义。
闭包捕获的是变量的引用，不是值
Go 的匿名函数形成闭包时，捕获的是外部变量的内存地址，不是创建闭包那一刻的副本。这意味着多个闭包共享同一变量，后续修改会影响所有闭包的执行结果。
常见错误现象：for 循环中直接在 goroutine 或回调里使用循环变量，导致所有闭包最终读到同一个值（通常是循环结束后的终值）。
- 正确做法：用局部变量显式拷贝值，例如
val := i，再在闭包中引用val - 或者把变量作为参数传入匿名函数：
func(v int) { ... }(i) - 注意：结构体字段、切片、map、channel 等复合类型本身是引用语义，即使“拷贝”变量，底层数据仍共享
defer 中的闭包捕获时机很关键
defer 语句注册时会立即求值函数参数，但闭包体本身延迟执行。如果闭包捕获了外部变量，而该变量在 defer 注册后又被修改，defer 执行时看到的就是修改后的值。
使用场景：资源清理、日志记录、性能计时等需要“延迟快照”的逻辑。
立即学习“go语言免费学习笔记（深入）”；
- 想捕获注册时的值？把变量作为参数传进闭包：
defer func(x int) { fmt.Println(x) }(i) - 避免在 defer 中直接引用可能变化的变量名，比如
defer func() { fmt.Println(i) }()在循环里极危险 - 注意：
recover()必须在 defer 函数内直接调用，不能放在嵌套闭包里，否则失效
逃逸分析决定闭包变量是否堆分配
Go 编译器会判断闭包捕获的变量是否“逃逸”出当前栈帧。若逃逸（比如闭包被返回或传给其他 goroutine），变量会被分配到堆上；否则保留在栈上，更高效。
性能影响：堆分配带来 GC 压力和间接访问开销；栈上变量生命周期明确、零成本。
- 用
go build -gcflags="-m"查看变量是否逃逸，搜索 “moved to heap” - 减少逃逸的方法：避免将闭包返回、避免在闭包中捕获大对象（如大数组、长字符串）
- 注意：哪怕只捕获一个字段，整个结构体也可能逃逸——编译器目前不支持字段级逃逸分析
闭包与方法值混用时 receiver 捕获易出错
当把某个实例的方法转为函数值（如 obj.Method），本质是生成一个闭包，捕获了 obj 的副本（值接收者）或地址（指针接收者）。这和手动写闭包行为一致，但容易被忽略。
常见错误现象：对值接收者方法取函数值后，修改原对象，闭包内仍看到旧值；对 nil 指针接收者调用，panic。
- 值接收者：
fn := obj.Method→ 闭包捕获的是obj当前副本，后续改obj不影响fn - 指针接收者：
fn := ptr.Method→ 闭包捕获的是ptr地址，后续改*ptr会影响fn - 别对 nil 指针取方法值再调用，运行时报
panic: value method XXX called on nil pointer
闭包机制本身不复杂，但变量捕获的“时机”和“方式”在不同上下文（循环、defer、方法值、goroutine）中表现差异很大，最容易被当成“直觉行为”跳过验证。实际写的时候，宁可多写一行显式传参，也别依赖隐式捕获的“看起来应该对”。