Go闭包捕获变量时，若该变量在外部函数返回后仍需存活，则编译器强制其逃逸到堆上；验证方式为go build -gcflags="-m -l"，出现“moved to heap”即确认逃逸。
func 返回另一个 func，且内部函数访问了外部函数的局部变量——这就是 Go 闭包最直白的识别方式。它不是语法糖，而是编译器主动介入、改变变量生命周期的真实机制。
闭包怎么判断是不是真捕获了变量？
关键看变量是否“逃逸”：如果内部函数引用了外部变量，且该变量在外部函数返回后仍需存活，Go 编译器就会把它分配到堆上。
验证方法很简单：
- 加
-gcflags="-m"编译，看到类似./main.go:5:2: moved to heap: count就说明变量被闭包捕获了 - 没这行输出，大概率只是值拷贝或未真正引用（比如只读且未跨作用域）
- 注意加
-l禁用内联，否则逃逸分析可能被干扰
为什么 for 循环里直接 defer 闭包总打印同一个数？
因为所有闭包共享同一个循环变量的地址，不是拷贝值。i 在循环结束时是终值，所有闭包读到的都是这个终值。
常见错误写法：
立即学习“go语言免费学习笔记（深入）”；
for i := 0; i < 3; i++ {
defer func() { fmt.Println(i) }() // 全部输出 3
}
修复方式只有两种：
- 显式创建新变量：
i := i（在循环体内重声明） - 把 i 当参数传入：
defer func(n int) { fmt.Println(n) }(i)
前者更常用，但本质都是切断对原变量的共享引用。
闭包里的变量是引用还是拷贝？
Go 闭包捕获的是变量的地址，不是值。这意味着：
- 修改闭包内捕获的变量，会影响后续调用（如计数器）
- 多个闭包如果来自同一外部作用域，且引用同一变量，它们会共享状态（除非变量在每次调用中重新声明）
- 但不同闭包实例之间互不干扰：每次调用
makeCounter()都生成独立的count堆变量
例如：counter1 和 counter2 的 count 是两个不同的堆地址，彼此无感知。
闭包性能和内存要注意什么？
闭包本身开销很小，但背后隐含的堆分配和 GC 压力容易被忽略：
- 每个闭包实例都会导致至少一个堆变量分配（被捕获的变量）
- 大量短期闭包（比如在 hot path 中频繁生成）可能增加 GC 频率
- 若捕获大结构体或切片，实际分配的是整个对象的堆副本（Go 不做深度拷贝，但指针仍指向原数据）
- 避免在循环内无节制地生成闭包，尤其当捕获变量较大或生命周期本应很短时
真正难调试的不是语法，而是变量生命周期延长后引发的意外持有——比如闭包无意中持有了大 map 或 open 的文件句柄，导致内存泄漏。
