defer 执行顺序为后进先出（LIFO），即按书写逆序执行；其变量捕获发生在 defer 语句执行时的值副本，而非函数返回时的最终值。
defer 语句的执行顺序是后进先出（LIFO）
Go 的 defer 不是“注册后立刻执行”，而是在外层函数即将返回前，按调用顺序的**逆序**执行。这意味着多个 defer 会像栈一样压入、弹出——最后写的 defer 最先执行。
这个特性在资源释放中极易引发问题：比如你先打开文件，再获取锁，然后用两个 defer 分别关文件和解锁，但若写成：
defer file.Close() defer mu.Unlock()
实际效果是：先 Unlock()，再 Close()。如果 file.Close() 内部可能 panic 或依赖锁保护（比如日志文件被多 goroutine 写），此时锁已释放，就可能触发竞态或 panic。
- 正确做法是让
defer的顺序与资源“释放依赖”一致：后获取的资源先释放 - 常见组合如
Open→Lock→defer Unlock→defer Close是错的；应写成defer Close在前，defer Unlock在后 - 不依赖注释推断顺序，直接按代码书写顺序检查栈行为
defer 中对变量的捕获发生在 defer 语句执行时，而非函数返回时
很多人误以为 defer 捕获的是变量“最终值”，其实它捕获的是**当时求值的副本**（对于非指针/非闭包类型）。比如：
for i := 0; i < 3; i++ {
defer fmt.Println(i) // 输出：3 3 3，不是 2 1 0
}
这是因为每次循环中 i 是同一个变量，defer fmt.Println(i) 捕获的是 i 的地址（值语义下是其当前值），等真正执行时 i 已变成 3。
- 资源释放场景中，若用循环启动多个 goroutine 并 defer 关闭对应连接，容易因变量复用导致关闭错连接
- 修复方式：用局部变量显式拷贝，如
id := i; defer fmt.Println(id) - 对指针、切片、map 等引用类型，捕获的是其头信息（如 len/cap/ptr），不是深层数据快照
panic/recover 会影响 defer 的实际执行时机和可见性
当函数内发生 panic，所有已注册但未执行的 defer 仍会执行（LIFO），但若某个 defer 内部也 panic，则原 panic 被覆盖——这会导致资源未释放或错误掩盖。
典型陷阱：在 defer 中调用 Close()，而该方法本身可能返回 error 或 panic（如 net.Conn.Close 在底层连接异常时可能 panic）。
- 永远不要假设
Close()安全：应包裹在recover()中，或至少检查 error（尽管多数io.Closer的Close()不 panic，但自定义资源可能） - 若需在 panic 后仍确保某资源释放（如临时文件清理），把它放在最外层
defer（即第一个注册的），保证它最后执行 -
recover()只在直接被defer包裹的函数中有效；写成defer func(){ recover() }()才生效，defer recover()无效
defer 在循环或条件分支中容易漏注册或重复注册
资源获取逻辑若嵌套在 if 或 for 中，defer 的放置位置稍有偏差，就会导致资源没被释放，或被多次释放（如 double-close）。
例如：
if needDB {
db, _ := sql.Open(...)
defer db.Close() // ✅ 正确：db 在作用域内，且一定会执行
}
// db.Close() 不会执行 —— defer 绑定到 if 块，但 Go 不允许在 block 内 defer 到外层函数
这段代码根本无法编译：db 在 if 块外不可见，而 defer 必须在能访问资源的同一作用域注册。
- 把资源获取和
defer放在同一作用域：要么提到外层声明，要么用立即执行函数（IIFE）封装 - 避免在循环里无条件
defer：比如for range connList { defer conn.Close() }会 close 所有连接，但都在函数末尾集中执行，可能早于业务逻辑完成 - 更安全的做法是显式管理生命周期：用
for+go func(c net.Conn){ c.Close() }(conn)，或改用sync.Pool/ 上下文取消机制
最常被忽略的一点：defer 不是魔法钩子，它只是函数返回前的一次性调度。一旦资源获取失败（比如 os.Open 返回 error），你根本没拿到资源，也就谈不上 defer 释放——这部分错误处理和提前 return 的路径，必须手动补全清理逻辑。
