defer 执行顺序为后进先出（LIFO），按注册逆序执行；参数在 defer 语句处即求值；在 return 写入返回值后、函数真正返回前执行，可修改命名返回值；panic 时仍执行，recover 必须在 defer 内调用。
defer 语句执行顺序是后进先出（LIFO）
多个 defer 语句在同一个函数中出现时，不是按书写顺序执行，而是按注册顺序的**逆序**执行。这点容易被直觉误导，尤其在嵌套或循环中注册 defer 时。
常见错误现象：以为先写的 defer fmt.Println("A") 会先打印，结果却是最后输出。
- 每次调用
defer都会把函数和当时求值的参数压入当前 goroutine 的 defer 栈 - 函数返回前（包括 panic 后的 recover 过程），从栈顶开始依次执行
- 参数在
defer语句执行时就完成求值（注意：不是执行时！），所以i := 0; defer fmt.Println(i); i++打印的是0
defer 与 return 的协作时机很关键
defer 在 return 语句“之后”但“函数真正返回之前”执行——准确说是：在 return 指令写入返回值、准备跳转前执行 defer 链。这使得 defer 可以修改命名返回值。
使用场景：资源清理 + 返回值修正，比如日志记录耗时、统一处理 error、关闭文件同时返回 err。
立即学习“go语言免费学习笔记（深入）”；
- 命名返回值（如
func foo() (err error)）在 defer 中可被修改；非命名返回值则不能 - 若函数 panic，defer 仍会执行，但 return 不会再发生；recover 必须在 defer 函数内调用才有效
- 不要在 defer 中调用
os.Exit()或直接 panic，会跳过其余 defer
示例：
func f() (result int) {
defer func() { result++ }()
return 1 // 实际返回 2
}
defer 在循环中容易误用导致闭包陷阱
在 for 循环里写 defer 是常见需求（如批量关闭文件），但若直接引用循环变量，所有 defer 会共享最后一次迭代的变量值。
错误写法：
for i := 0; i < 3; i++ {
defer fmt.Println(i) // 输出 3 次 "3"
}
- 根本原因是：i 是循环变量，地址不变，defer 捕获的是变量地址，而非值
- 正确做法：显式传参（
defer fmt.Println(i)→defer func(x int) { fmt.Println(x) }(i)）或在循环内定义新变量（for i := 0; i ） - 注意性能：频繁创建匿名函数可能带来小对象分配，高并发循环中需权衡
defer 不是万能的，该用 defer.Close 还是手动 close？
对实现了 io.Closer 接口的类型（如 *os.File、*sql.Rows），是否总该用 defer xxx.Close()？答案是否定的。
- 文件读写：建议 defer，因为 Close 失败通常不致命，且生命周期明确
- 数据库连接/事务：一般不用 defer，因为 Close 可能阻塞或失败，影响后续逻辑；应显式检查 err 并及时释放
- HTTP 响应体：
resp.Body必须 close，但应在读取完后立即 close，而非 defer —— 否则连接无法复用，造成连接池耗尽 - defer 的开销虽小（约 3–5ns），但在高频循环或性能敏感路径中，可考虑手动管理
容易被忽略的一点：defer 注册本身有微小成本，且它把资源释放推迟到函数退出，可能延长对象生命周期，影响 GC 时机。
