defer闭包捕获变量地址而非值快照，执行时读取最新值；for循环中需用f:=f或传参避免复用变量；defer参数立即求值，闭包变量延迟读取；panic时defer仍执行但需注意变量作用域。
defer 闭包里读的不是“当时值”，而是“执行时的变量当前值”
go 的 defer 后跟闭包时，闭包捕获的是变量的地址，不是注册那一刻的值快照。这意味着：只要那个变量后续被修改，所有 defer 闭包在真正执行时看到的都是最新值。
常见错误现象：for i := 0; i < 3; i++ { defer func() { println(i) }() } 输出全是 3，而不是 0、1、2。
- 根本原因：循环变量
i在整个循环中复用同一块栈内存，所有闭包共享&i - defer 注册不等于立即执行，但闭包绑定关系在注册时就已确定
- 哪怕你在 defer 后立刻改
i，也不会影响已注册的闭包——除非你改的是它引用的那个变量本身
循环中 defer 涉及文件、锁、HTTP 客户端时怎么写才安全
资源清理类 defer 最容易踩坑：比如遍历文件列表并延迟删除，结果只删了最后一个；或在循环中打开多个数据库连接，却只关了最后一个。
正确做法不是“避免 defer”，而是切断变量复用链：
- 用短变量声明“快照”当前值：
for _, f := range files { f := f; defer os.Remove(f.Name()) } - 显式传参进闭包：
for _, f := range files { defer func(name string) { os.Remove(name) }(f.Name()) } - 别写
defer f.Close()然后在循环里反复给f赋新值——每次f被覆盖，旧的句柄就丢了
defer 参数求值时机 vs 闭包变量捕获，两个机制必须分清
这是最容易混淆的点：defer fmt.Println(i) 和 defer func() { fmt.Println(i) }() 行为完全不同。
立即学习“go语言免费学习笔记（深入）”；
-
defer fmt.Println(i)：参数i在defer语句执行到那一刻就求值并拷贝，之后改i不影响它 -
defer func() { fmt.Println(i) }()：闭包捕获变量i本身，执行时读的是函数返回前i的最终值 - 混合写法如
defer func(v int) { fmt.Println(v) }(i)：参数i立即求值传入，闭包内v是独立副本，最可控
panic 场景下 defer 仍执行，但变量作用域可能出人意料
很多人以为 defer 能“兜住 panic”，其实它只保证执行时机，不改变控制流。更隐蔽的问题是变量可见性：
-
defer log.Printf("err: %v", err)放在函数开头，但err是后面:=声明的 → defer 中err不可见，输出<nil> - 解决办法：提前声明
var err error，再在具体分支赋值；或把 defer 移到if err != nil分支内部 -
recover()必须在 defer 的匿名函数里直接调用：defer func() { recover() }()有效；defer recover()无效（立即执行）
实际写代码时，最常被忽略的是：defer 执行顺序是 LIFO，但变量绑定发生在注册时刻，而闭包读值发生在执行时刻——这三个时间点未必重合，且各自受不同规则约束。 写的时候多看一眼变量生命周期，比事后 debug 省力得多。
