闭包捕获的是变量内存地址而非值快照，所有共享该变量的闭包均读取其最新值；典型错误是for循环中多个闭包输出同一终值，修复需每次迭代创建新变量或传参。
闭包捕获的是地址，不是值
Go 闭包捕获的是变量的内存地址，不是定义时的值快照。这意味着所有共享同一变量的闭包，读到的始终是该变量当前的最新值。
常见错误现象：for i := 0; i 执行后全部输出 <code>3，不是因为 goroutine 调度慢，而是所有闭包都持有对同一个 i 的指针，循环结束时 i 已变成 3。
- 基本类型（
int、string）看似“值语义”，但闭包绑定的是变量本身，不是复制后的副本 - 结构体或切片被闭包捕获时，不会拷贝整个对象；闭包持有的是原变量地址
-
defer中的闭包也遵循此规则：注册时不读值，执行时才读——所以defer func() { println(i) }()输出的是函数返回前那一刻的i
Go 1.22+ 对 range 的隐式按值捕获优化
从 Go 1.22 开始，编译器对 for _, v := range slice 中的 v 做了自动按值捕获优化：每次迭代会为 v 分配独立栈空间，避免复用导致的闭包误读。
但这仅适用于切片和 map 的 range；自定义迭代器、传统 for 循环、或 range 外部变量仍需手动处理。
立即学习“go语言免费学习笔记（深入）”；
- 安全写法：
for i, v := range items { go func(idx int, val T) { process(idx, val) }(i, v) } - 危险操作：
go func() { process(v) }()——v可能被下一轮覆盖，甚至解引用已失效内存 - 若需元素地址，必须用
&items[i]，绝不能用&v
闭包延长变量生命周期，容易拖住大对象
只要闭包还被引用，它捕获的变量就不会被 GC 回收——哪怕外层函数早已返回。这不是内存泄漏，但会导致意料之外的内存驻留。
典型风险场景：http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) { use(r.Body) }) → 整个 *http.Request 可能长期驻留堆上。
- 排查方法：
go tool compile -m查看逃逸分析，确认哪些变量被抬升到堆 - 安全做法：缩小捕获范围，比如只传
r.URL.Path而非整个r - 避免捕获大 struct、大 slice，尤其不要在全局 map 或 goroutine 中存闭包
命名返回值 + defer 修改会覆盖 return 值
命名返回值会被闭包修改，且修改发生在 return 语句之后、函数真正退出之前，容易被忽略。
示例：func foo() (x int) { x = 1; defer func() { x = 2 }(); return } 实际返回 2，不是 1。
- 混合写法陷阱：
defer func(x int) { println(x, i) }(i)——x是注册时求值，i是执行时读取 - 想冻结注册时的值，必须显式复制：
i := i; defer func() { println(i) }() - 这种行为没有 panic、没有报错，只表现为逻辑不一致，调试时需特别留意 defer 与命名返回值的组合
