defer 后面的函数参数在 defer 语句执行时立即求值，而非 defer 实际调用时；例如 defer fmt.println(i) 会立刻捕获 i 的当前值，后续修改不影响该 defer。
defer 后面的函数参数什么时候计算？
不是 defer 执行时才算，而是 defer 语句被**执行到那一刻**就立刻求值——哪怕函数还没调用。这是绝大多数人踩坑的根源。
比如你写 defer fmt.Println(i)，i 的当前值当场锁定；后续再改 i，对这个 defer 没影响。
- 常见错误现象：循环里 defer 闭包，结果所有 defer 都打印最后一个值
- 典型场景：
for i := 0; i 输出 2、2、2（不是 0、1、2） - 解决办法：用局部变量或匿名函数捕获当前值，例如
defer func(v int) { fmt.Println(v) }(i) - 注意：传指针进去的话，defer 执行时读的是指针指向的最新值，和值传递行为完全不同
defer 调用链中变量修改会影响前面的 defer 吗？
不会——前提是那些 defer 已经完成了参数求值。但如果你 defer 的是函数字面量（闭包），而它引用了外部变量，那它看到的就是运行时的最新值。
关键区分点：是「值拷贝」还是「变量捕获」。
立即学习“go语言免费学习笔记（深入）”；
-
defer fmt.Printf("%d", x)→x值在 defer 语句执行时快照，之后改x无效 -
defer func() { fmt.Printf("%d", x) }()→ 闭包捕获x变量本身，defer 实际执行时读的是当时x的值 - 性能影响：闭包 defer 比普通函数调用稍重（有环境捕获开销），但通常可忽略
- Go 1.22+ 对部分简单闭包做了优化，但别依赖——行为逻辑没变
多个 defer 的执行顺序和 panic 场景下怎么工作？
后进先出（LIFO），和栈一样；panic 不会跳过 defer，反而会强制触发所有已注册但未执行的 defer。
但要注意：如果某个 defer 里也 panic，它会覆盖前一个 panic（除非用 recover 拦住）。
- 常见错误：在 defer 里打开文件又忘记检查
Close()返回的 error，导致资源泄露或静默失败 - 正确姿势：
defer func() { if err := f.Close(); err != nil { log.Println("close failed:", err) } }() - 兼容性：所有 Go 版本行为一致，但 Go 1.21+ 开始支持
defer在函数体外使用（仅限 go test 中的 init），生产代码不用管 - 别在 defer 里做耗时操作（比如网络请求），它会在函数 return 后才跑，可能拖慢调用方
defer 和 return 语句之间隐藏的赋值时机
Go 在 return 之前会先处理命名返回值的赋值，然后才执行 defer——这意味着 defer 可以读/改命名返回值。
这是少数能让 defer “影响返回结果”的合法方式，但极易误用。
- 示例：
func f() (err error) { defer func() { if err == nil { err = errors.New("forced") } }(); return nil }→ 实际返回 forced error - 陷阱：如果 return 是非命名值（如
return nil），defer 就无法修改返回值 - 为什么这样设计：为了支持 cleanup + 错误增强这类模式，但过度依赖会让控制流难推理
- 建议：只在极明确的场景（比如统一日志、错误包装）用，别用来“绕过”正常返回逻辑
最麻烦的不是 defer 本身，而是它把「声明时刻」和「执行时刻」拆开了——而参数求值卡在中间那个瞬间。盯住那一行 defer 语句被执行的时刻，几乎所有困惑都能解开。
