defer语句在函数返回前执行，注册时立即求值参数并压栈，执行时按后进先出（lifo）顺序；多个defer逆序执行，命名返回值可被defer修改，匿名返回值则不可。
defer 语句在函数返回前执行，但不是“函数退出瞬间”才开始运行——它在 defer 语句被求值时就注册，实际调用顺序是后进先出（LIFO），且参数在 defer 时即确定。
defer 语句的注册时机和参数绑定
很多人误以为 defer 是等到函数 return 才去“看一眼”要调什么，其实不然：每遇到一条 defer 语句，Go 就立即对它的函数名和参数做一次求值，并把这次调用“压栈”；return 之后再按栈逆序弹出执行。
这意味着：
- 如果参数是变量，它的值在
defer那行就被捕获，后续修改不影响该次延迟调用 - 如果参数是表达式（如
foo()），它会在defer行执行并保存返回值，不是延迟到 return 时再算 - 闭包中引用外部变量，捕获的是变量本身（地址），不是快照值——这点容易踩坑
示例：
func example() {
i := 0
defer fmt.Println(i) // 输出 0，不是 1
i++
return
}
多个 defer 的执行顺序：LIFO 不等于代码顺序
虽然 defer 写在代码里从上到下，但执行是反过来的。这在嵌套资源释放、锁释放、日志记录等场景直接影响行为正确性。
典型错误是认为“先 defer open，后 defer close”，close 就一定在 open 之后执行——没错，但若中间又 defer 了别的东西，顺序就变了。
要点：
- 每个
defer独立压入当前 goroutine 的 defer 栈 - 函数 return 后，按压栈逆序依次调用，类似
stack.Pop() - panic/recover 也走同一套机制，
defer仍会执行（除非 os.Exit）
示例：
func order() {
defer fmt.Print("A")
defer fmt.Print("B")
defer fmt.Print("C")
// 实际输出：CBA
}
defer 和 return 的交互：命名返回值 vs 匿名返回值
当函数有命名返回值时，defer 中能访问并修改它；匿名返回值则不能——这是 Go 编译器生成的临时变量机制导致的差异。
这个细节直接决定你能否在 defer 中统一处理错误或日志：
- 命名返回值（如
func foo() (err error)）：defer可读可写该变量 - 匿名返回值（如
func foo() error）：defer只能读取最终返回值的副本，无法修改实际返回结果 - 所有
defer在 return 语句赋值完成后、真正跳转前执行
常见用途：在命名返回值函数中用 defer 统一记录耗时或补日志，但别指望靠它“覆盖” panic 后的返回值。
defer 性能开销与适用边界
每次 defer 调用都有少量运行时开销（栈帧管理、函数指针存储），在高频循环或极致性能路径中需谨慎。但日常 HTTP handler、DB 操作这类 IO-bound 场景，完全不必担心。
关键判断点：
- 单次函数中 defer 超过 3–5 个？考虑提取为辅助函数或手动管理
- 在
for循环内写defer？几乎总是错的——会导致大量 defer 堆积，直到外层函数结束才执行 - 替代方案：显式
Close()+if err != nil { ... }更可控，但易漏 - 标准库如
sql.Rows、http.Response.Body的文档明确建议 defer，因为它们本就是短生命周期资源
真正容易被忽略的是：defer 不是万能资源守门员。比如 goroutine 泄漏、channel 未关闭、time.Timer 未 Stop，defer 都无能为力——它只管当前函数栈。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
