defer 中的变量是“引用”而非“快照”；它捕获的是变量的绑定关系，执行时取当前值，故循环中直接 defer 使用循环变量会导致全部输出终值。
defer 中的变量是“快照”还是“引用”？
Go 的 defer 不会捕获变量当时的值，而是捕获变量的“绑定关系”——在函数返回前真正执行 defer 语句时，它看到的是变量**当前的值**，不是定义时的值。这在闭包场景下特别容易出错。
典型现象：for 循环里用 defer 打印索引，结果全打印最后一个值。
- 原因：所有
defer共享同一个循环变量i的内存地址，等函数结束统一执行时，i已经是终值 - 解决本质：让每次
defer绑定一个独立的值，而不是共享变量 - 最直接做法：在
defer前用局部变量“快照”一次，比如idx := i; defer fmt.Println(idx) - 注意：不能靠
defer func(i int) { ... }(i)()这种方式“传参”来绕过——虽然语法合法，但容易误以为能自动捕获，其实只是显式传参，仍需确保调用时机和参数值正确
defer + 匿名函数参数传值 vs 变量捕获
匿名函数本身是否捕获外部变量，和 defer 无关；关键在于你如何构造这个匿名函数以及何时求值。
常见错误写法：for i := 0; i → 输出全是 <code>3。
-
func() { fmt.Println(i) }是一个闭包，它引用了外部变量i，不是复制 - 正确写法一（推荐）：
for i := 0; i —— 用短变量声明在每次迭代中创建新绑定 - 正确写法二：
for i := 0; i —— 显式传参，<code>i在defer语句执行时立即求值并传入 - 性能差异极小，但后者更易读、更少依赖作用域规则，适合团队协作
panic/recover 场景下 defer 的执行顺序与变量可见性
当函数因 panic 返回时，defer 依然按后进先出顺序执行，但此时所有已声明但未初始化的变量（比如 err 被 := 声明在 if err != nil 分支里）在 defer 中不可见或为零值。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型坑：defer log.Printf("err: %v", err) 放在函数开头，但 err 实际在后面才声明或赋值。
- 错误现象：日志里
err总是<nil></nil>或默认零值，哪怕 panic 前刚赋过值 - 根本原因：
err不在defer所在作用域内，或被遮蔽（shadowed） - 安全做法：把需要记录的变量提前声明（如
var err error），再在后续逻辑中赋值；或者把defer移到具体错误分支内部 - 额外注意：
recover()必须在defer的匿名函数中直接调用，写成defer recover()是无效的——因为recover()立即执行，不是延迟执行
defer 在方法接收者上修改字段值是否生效？
取决于接收者类型：值接收者不会影响原对象，指针接收者才会。但很多人忽略的是——defer 里的方法调用，其接收者是在 defer 注册时就确定的，不是执行时。
例如：obj := &MyStruct{}; defer obj.Close()，如果 Close() 是指针方法，没问题；但如果中间又给 obj 赋了新地址，defer 仍调用原始 obj 的 Close()。
- 现象：改了接收者变量，但
defer还是操作旧对象 - 本质：
defer记录的是“调用表达式”，包括当时求值出的接收者值（地址或副本） - 建议：避免在
defer后重新赋值接收者变量；如必须，应显式在defer前做快照，比如o := obj; defer o.Close() - 结构体字段修改同理：值接收者方法无法修改原结构体字段，这点和普通函数调用一致，不是
defer特有，但容易在延迟上下文中忽略
最常被忽略的一点：defer 行为不依赖代码缩进或视觉位置，而严格依赖语句执行顺序和变量作用域。写的时候别凭感觉，要盯着变量生命周期看。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
