defer闭包读取的是执行时的变量当前值，因其捕获变量地址而非快照；而defer语句参数在注册时即求值并拷贝。
defer 闭包里读到的到底是注册时的值，还是执行时的值？
读到的是执行时的值——但前提是闭包真正捕获了变量，而不是参数传值。这是最常被误解的一点：很多人以为 defer func() { println(i) }() 会打印注册时的 i，结果发现全是循环终值；另一些人又误以为 defer fmt.Println(i) 会延迟读取 i，结果发现打印的是注册那一刻的快照。
根本区别在于：defer fmt.Println(i) 是参数立即求值（值拷贝），而 defer func() { println(i) }() 是闭包捕获变量地址——两者语义完全不同。
-
defer fmt.Println(i)→i在这一行执行时就被读取并拷贝，后续改i没影响 -
defer func() { println(i) }()→ 闭包持有对i的引用，执行时读的是当时内存里的值 - Go 1.21+ 中，
for i := range xs每次迭代都新建i变量（地址不同），但闭包仍可能读错——因为所有闭包都指向各自迭代中那个i的最终地址（若该变量已失效或被复用）
为什么 for 循环里直接写 defer func() { use(i) }() 总是出错？
因为所有闭包共享同一个变量绑定，哪怕 Go 1.24 每次迭代分配新栈地址，只要闭包没在迭代内做显式绑定，它们仍会读到最后一次迭代后残留的值（或 panic 读悬空地址）。
典型错误现象：for i := 0; i < 3; i++ { defer func() { fmt.Print(i) }() } 输出 333，不是 012。
立即学习“go语言免费学习笔记（深入）”；
- 正确解法一（短变量声明）：
for i := 0; i < 3; i++ { i := i; defer func() { fmt.Print(i) }() } - 正确解法二（参数传值）：
for i := 0; i < 3; i++ { defer func(val int) { fmt.Print(val) }(i) } - 错误写法：
defer func() { fmt.Print(i) }()后多加括号 →defer func() { fmt.Print(i) }()（末尾()表示立即执行，不是注册 defer）
defer 闭包里调用 recover() 为什么有时收不到 panic？
recover() 只在 defer 绑定函数的最外层有效。一旦闭包里再套一层函数、或者起 goroutine，recover() 就失效——不是语法错，而是运行时上下文丢失。
- ✅ 安全写法：
defer func() { if r := recover(); r != nil { log.Printf("panic: %v", r) } }() - ❌ 无效写法：
defer func() { func() { recover() }() }()→ 内层函数无 panic 上下文 - ❌ 无效写法：
defer func() { go func() { recover() }() }()→ 新 goroutine 不继承原函数的 panic 状态 - 注意：
recover()必须紧跟在 defer 函数体第一级，不能被任何控制流（if/for/func 调用）包裹
defer 闭包捕获大对象（如 *http.Request）有什么风险？
会强制变量逃逸到堆，延长 GC 周期，还可能拖慢 CPU 缓存命中率——尤其在 HTTP handler 这类高频路径上。
- 验证方式：
go build -gcflags="-m" main.go，搜索escapes to heap - 安全替代：
defer func(id string, code int) { log.Println(id, code) }(req.Header.Get("X-Request-ID"), http.StatusOK) - 危险写法：
defer func() { log.Printf("req: %+v", req) }()→ 整个*http.Request被捕获，即使只用了其中一两个字段 - 更隐蔽的坑：闭包里引用了
req.Body（io.ReadCloser），可能导致 body 未被及时关闭或重复读取
