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 语句**被执行到的那一行**就完成求值，之后变量再变，不影响已入栈的参数值。

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 的“延迟”是函数级的，不是语句级的；它不解决并发竞争，也不自动处理错误传播 —— 它只是给你一个确定的、最后的机会。