闭包在defer中读取的是执行时变量的当前值而非注册时快照，因捕获变量地址而非副本；循环中所有defer共享同一变量地址，导致输出全为终值。
闭包在 defer 中读到的不是“注册时的值”，而是“执行时的值”——这直接导致循环变量全输出最后一个值、日志里 err 总是 <nil></nil> 等典型问题。
defer 闭包捕获的是变量地址，不是快照值
Go 的闭包不拷贝外部变量，只保存指向它的指针。当 defer 注册后并未立即执行，而是在函数返回前才调用闭包，此时变量可能已被多次赋值。
- 常见错误现象：
for i := 0; i → 输出全是 <code>3 - 根本原因：循环变量
i是同一块栈内存反复写入，所有闭包都读同一个地址 - 命名返回值同理：
func f() (x int) { x = 1; defer func() { x = 2 }(); return }→ 实际返回2，因为return触发defer执行，但x尚未真正传出
怎么让 defer 闭包拿到“当时值”
必须切断变量复用链，让每次迭代或每次注册都有独立绑定。
- 推荐方式：在循环体内加短变量声明
i := i，再在闭包中用这个新变量for i := range files { i := i; defer os.Remove(files[i]) } - 等效方式：用带参数的匿名函数，参数在
defer语句执行时立即求值for _, f := range files { defer func(name string) { os.Remove(name) }(f.Name()) } - 禁止写法：
defer func() { ... }()末尾多了一对括号 → 立即执行，不是延迟注册
defer 闭包传参 vs 直接引用对逃逸的影响
直接引用外部变量会强制该变量逃逸到堆；显式传参可避免，这对高频路径（如 HTTP handler）很关键。
- 逃逸验证：
go build -gcflags="-m" main.go，搜escapes to heap - 传参写法：
defer func(val int) { fmt.Println(val) }(i)→i不逃逸 - 混用写法：
defer func(val int) { fmt.Println(val, i) }(i)→i仍逃逸，且语义混乱 - 大对象慎捕获：
*http.Request、几 MB 的[]byte被闭包捕获，会延长 GC 周期、降低 CPU 缓存局部性
recover() 必须在 defer 直接绑定的函数第一层调用
recover() 只在 defer 所绑定函数体最外层有效，嵌套一层就失效。
- 安全写法：
defer func() { if r := recover(); r != nil { handle(r) } }() - 无效写法：
defer func() { func() { recover() }() }()→ 编译无错，但永远收不到 panic - 也无效：
defer func() { go func() { recover() }() }()→ 新 goroutine 无 panic 上下文
真正难的不是记住规则，而是意识到：哪怕只是捕获一个 int，只要它出现在 defer func() { use(x) }() 里，x 就已逃逸；而一旦逃逸，就算函数最终没 panic、defer 没执行，这块内存也早被移到堆上了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
