go闭包捕获的是变量的引用（内存地址），非值拷贝；多个闭包共享同一变量，修改相互影响，典型错误是for循环中闭包均输出最后一次迭代值。
闭包变量被捕获的是值还是引用？
Go 闭包捕获的是变量的引用（更准确地说：是变量在栈/堆上的内存地址），不是快照式的值拷贝。这意味着多个闭包共享同一变量，修改会影响所有闭包行为。
- 常见错误现象：
for循环中创建多个闭包，却都打印最后一个迭代值，例如：
for i := 0; i
- 根本原因：
i是循环变量，所有闭包共享同一个i的地址；循环结束时i == 3，所以每个闭包执行时读到的都是3 - 正确做法：用局部参数传入当前值，切断共享引用
for i := 0; i
- 替代写法：在循环体内声明新变量
val := i，再闭包捕获val—— 因为每次迭代都新建了绑定
defer + 闭包组合时的坑
defer 延迟执行的函数若含闭包，其参数求值时机极易混淆：参数在 defer 语句执行时求值（即“立即求值”），而闭包体在真正 defer 触发时才执行（“延迟执行”）。
- 典型陷阱：误以为闭包内所有表达式都延迟求值
- 示例中
fmt.Println(i)的i是延迟读取，但defer func(i int)的i是定义时就取值 - 如果闭包不带参数，又没做隔离，就会复用外部变量最新状态
- 性能影响：不当使用可能延长变量生命周期，阻止 GC 提前回收（尤其闭包持有大对象指针时）
闭包和 goroutine 配合要注意什么？
在 go 关键字后启动闭包，和 defer 类似，但并发下问题更隐蔽——goroutine 启动几乎瞬间返回，主协程可能很快退出，导致闭包还没来得及执行，或执行时依赖的变量已被回收（尤其逃逸分析未触发堆分配时）。
- 常见错误现象：启动一堆 goroutine 打印循环变量，结果全输出相同值，或 panic
invalid memory address - 必须确保闭包捕获的变量在 goroutine 运行期间有效：优先传参，避免直接捕获循环变量或短生命周期局部变量
- 示例修正：
for i := range items {
go func(id int) {
fmt.Println("handling", id)
}(i) // ✅ 显式传参
}
- 反模式：
go func() { fmt.Println(i) }()❌（i可能已变，或循环结束，或栈被复用）
闭包逃逸与内存分配怎么看？
Go 编译器会根据闭包是否“逃逸”决定变量分配位置：若闭包被返回、传入函数、或赋值给全局变量，捕获的变量大概率会从栈移到堆——这直接影响性能和 GC 压力。
- 验证方式：加
-gcflags="-m"编译，观察类似... escapes to heap的提示 - 一个闭包即使只捕获一个
int，只要它逃逸，整个闭包结构（含上下文环境）都会堆分配 - 容易被忽略的点：把闭包作为返回值、塞进切片、传给
context.WithValue等，都可能触发逃逸 - 没有银弹：该用闭包时别硬拆，但对高频调用路径（如 HTTP 中间件、循环内工厂函数），建议用结构体+方法替代复杂闭包，更可控
闭包本身轻量，但它的生命周期、捕获变量的生命周期、以及是否逃逸，三者交织在一起，稍不注意就变成隐性内存泄漏或竞态源头。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
