defer是Go资源管理的事实标准机制，解决释放时机可控性问题；参数在defer语句执行时求值而非返回时，循环中直接使用迭代变量会导致全部捕获终值；多个defer按LIFO顺序执行，需严格匹配资源获取逆序。
defer 不是“语法糖”，也不是可有可无的辅助工具——它是 Go 资源管理的事实标准机制，直接决定了你写的代码是否会在高并发或异常路径下泄漏文件句柄、锁、连接或内存。
它不解决“要不要释放资源”的问题，而是解决“释放时机是否可控、是否确定”的问题。用错 defer，比不用还危险。
defer 参数求值发生在 defer 语句执行时，不是函数返回时
这是绝大多数闭包相关 bug 的根源。比如循环中直接 defer f.Close() 或 defer fmt.Println(i)，变量 i 在所有 defer 注册完后早已变成终值。
- 错误写法：
for _, t := range ts { defer t.Close() }→ 全部输出c closed - 正确写法之一：
for _, t := range ts { t := t; defer t.Close() }（显式复制） - 正确写法之二：
for i := range ts { defer func(idx int) { ts[idx].Close() }(i) }（传参捕获）
关键不是“怎么绕过”，而是理解：参数在 defer 那一行就求值完毕，闭包引用的是变量本身，不是快照。
立即学习“go语言免费学习笔记（深入）”；
defer 方法调用 vs 普通函数调用，receiver 类型影响行为
defer t.Close() 中如果 t 是值类型，Close() 实际操作的是该次循环中 t 的副本；而 defer (&t).Close() 或 defer ptr.Close() 才真正作用于原对象。
- 值接收者方法：修改 receiver 不影响原结构体，但
defer后续执行时可能已失效（如t是局部拷贝） - 指针接收者方法：必须确保指针有效，否则 panic；常见于
defer file.Close()，因为file是指针类型 - 切片/映射遍历时，
range的value是副本，defer value.Close()等价于对副本调用，大概率出错
多个 defer 的 LIFO 执行顺序直接影响资源释放逻辑
文件打开后立即 defer file.Close() 是安全的，但如果中间又加了 defer log.Printf(...)，而日志写入依赖文件句柄——那就会 panic，因为 file.Close() 先于日志执行。
- 原则：清理顺序要和获取顺序相反，比如先
lock()再open()，就应该先defer close()再defer unlock() - 不要把带副作用的
defer和纯记录类defer混排，尤其当它们存在依赖关系时 -
recover()必须放在最外层defer中，且不能被其他defer干扰执行时机
defer 不是万能的，超长生命周期或条件释放场景需手动控制
defer 绑定到函数作用域，一旦注册就一定会执行。但有些资源需要“按需释放”或“提前释放”，比如连接池中的连接、缓存中预加载的数据。
- 典型反例：
if err != nil { defer conn.Close() }——defer无法条件注册，这行代码永远会注册，即使conn是 nil - 正确做法：用普通
if+ 显式conn.Close()，或封装成带判断的 helper 函数 - 性能敏感路径（如高频小函数），
defer带来的栈帧开销和延迟虽小，但可测；这时应权衡可读性与微秒级成本
真正难的不是记住“后进先出”或“函数返回时执行”，而是判断：这个资源的生命周期，是否严格绑定于当前函数的退出？它的依赖项是否也由同一函数管理？
漏掉这一层判断，defer 就会从保障变成隐患。
