defer 的核心作用是“预约清理动作”，确保函数退出前一定执行，无论是否 panic 或提前 return；它通过将函数调用压入 defer 栈、在 return 后逆序执行来防止资源泄漏，支持参数声明时求值、命名返回值修改及跨作用域安全使用。
defer 的核心作用是“预约清理动作”，确保函数退出前一定执行，无论是否 panic 或提前 return。
为什么 defer 能保证资源不泄漏？
Go 没有析构函数或 try-finally，defer 是语言层面对“成对操作”的原生支持。它把函数调用压入当前 goroutine 的 defer 栈，等到外层函数的 return 指令执行完毕（包括写入返回值）、但尚未真正退出时，才按栈顺序逆序执行。
- 即使中间
panic()，所有已注册的defer仍会执行 —— 这是避免死锁（如忘记mu.Unlock()）和文件句柄泄漏的关键 -
defer不改变控制流，不阻塞后续语句，写在开头也完全 OK - 它不依赖 作用域（不像 C++ RAII），只绑定到函数生命周期，所以跨 if/for 块也安全
多个 defer 的执行顺序：LIFO 是铁律
后声明的 defer 先执行，这是由底层栈结构决定的，不是约定而是实现机制。这对嵌套资源释放至关重要 —— 比如先开文件 A、再开文件 B，就得先 defer B.Close() 再 defer A.Close()，才能保证关闭顺序正确。
func example() { f1, _ := os.Open("a.txt") defer f1.Close() // 后执行 f2, _ := os.Open("b.txt") defer f2.Close() // 先执行 → 关闭 b.txt，再关 a.txt}- 错误做法：
defer f1.Close()写在f2后面，却期望先关f1—— 一定会错 - 调试技巧：在每个
defer里加日志，比如defer fmt.Println("closing f1")，能直观验证顺序
参数求值时机：声明即快照，不是执行时取值
defer 后面函数的参数，在 defer 语句 ** 被执行到的那一行 ** 就完成求值，之后变量再变，不影响已入栈的参数值。
立即学习“go 语言免费学习笔记（深入）”；
func demo() { x := 1 defer fmt.Println(x) // x=1 被立即捕获 x = 2 return }- 常见坑：用
defer fmt.Println(i)打印循环变量，结果全输出最后一个值 —— 因为i是同一个变量，所有defer都捕获了它的最终地址（而值已变） - 修复方式：传副本，比如
defer func(v int) {fmt.Println(v) }(i)，或在循环内用新变量val := i; defer fmt.Println(val) - 闭包同理：若
defer中引用外部变量，且该变量后续被修改，结果取决于你是否捕获了它的当前值
defer 和命名返回值的交互：能改返回值，但要小心
当函数有命名返回值（如 func() (result int)）时，defer 中的匿名函数可以读写这个变量，从而影响最终返回值。这在日志、错误包装等场景有用，但容易引发逻辑混淆。
func tricky() (result int) {result = 5 defer func() {result += 10}() // 最终返回 15 return // 注意：这里 return 不带值，才让 defer 修改生效}- 如果写成
return 5，则result被赋值为 5 后立即返回，defer修改的是已写入的返回槽，但 Go 规范允许这种行为 - 不推荐依赖此特性做主逻辑，更适合用于统一埋点、状态标记等副作用操作
- 更安全的做法：用普通返回值 + 显式赋值，把副作用逻辑从返回值决策中解耦
真正难的不是记住 LIFO 或参数求值，而是意识到 defer 的“延迟”是函数级的，不是语句级的；它不解决并发竞争，也不自动处理错误传播 —— 它只是给你一个确定的、最后的机会。
