多个 defer 按后进先出（LIFO）顺序执行，即最后声明的 defer 最先运行；其参数在 defer 语句出现时即求值，而非执行时。
多个 defer 为什么不是从上往下执行
Go 把每个 defer 压入函数内部的一个栈，函数返回前统一出栈执行，所以是后进先出（LIFO）——最后写的 defer 最先运行。这不是 bug，是设计使然。
常见错误现象：以为按代码顺序关闭资源，结果 file.Close() 在 db.Close() 之后注册，却先执行了，导致数据库连接已关但事务还在用，panic 或数据不一致。
- 所有已注册的
defer都会在函数返回前执行，无论 return、panic 还是正常结束 - 想控制释放顺序？别靠写代码的上下位置，靠注册时机：把要**先执行**的逻辑，写在**后面**的
defer里 - 比如要“先关事务、再关连接”，就得先写
defer tx.Close()，再写defer db.Close()
defer 参数什么时候求值：为什么循环里总是输出同一个值
defer 后面函数的参数，在 defer 语句**出现那一刻就求值完毕**，不是等到真正执行时才取。这是最常踩的坑之一，尤其在 for 循环中。
错误写法：for i := 0; i → 输出全是 <code>3
立即学习“go语言免费学习笔记（深入）”；
正确写法：for i := 0; i → 输出 <code>0、1、2
- 根本原因：闭包捕获的是变量
i的地址，循环结束时i == 3，所有defer都读到这个最终值 - 用立即传参的匿名函数，是把当前轮次的值
i拷贝进去，实现“注册时快照” - 这个陷阱和
goroutine中的循环变量问题本质相同，但defer更隐蔽，因为不报错、只逻辑错
defer 和 return 谁先谁后：能改返回值吗
return 分两步：先计算并写入返回值（到寄存器或栈帧），再执行所有已注册的 defer，最后跳出去。这意味着 defer 可以读写**命名返回值**。
示例：func f() (result int) { result = 100; defer func() { result++ }(); return } → 返回 101
- 匿名返回值（如
func() int）无法被defer直接修改，因为没名字、没地址 - 命名返回值（如
func() (x int)）在函数声明时就分配了内存，defer可以访问并修改它 - 指针返回值也适用：如果返回的是
*int，defer改的是指针指向的值，调用方会看到变化
defer 的实际清理顺序容易被忽略的依赖点
资源释放必须严格按依赖逆序：后打开的先关，子资源先于父资源释放。比如 os.OpenFile 后 bufio.NewReader，就得先 defer reader.Close()（如果它有），再 defer file.Close()；又比如加锁后开 goroutine，解锁必须在 goroutine 完全退出后才能安全进行，否则可能 race。
这些顺序不是靠“写得靠下”保证的，而是靠注册时机 —— 把依赖上游的 defer 写在更靠近函数末尾的位置。
高频调用中大量 defer 会有性能开销（栈操作 + 函数调用封装），简单场景如单次 file.Close() 没问题，但循环内每轮都 defer 就该警惕。
