defer 执行顺序与底层原理，90% 的人都理解不全

defer 执行顺序与底层原理，90% 的人都理解不全

---

先亮结论：defer 不是"排队等执行"，而是"压栈后逆序弹出"

多数人以为 defer 就是"把函数推迟到后面跑"，于是下意识按代码书写顺序去推断执行顺序------大错特错。

Go 的 defer 是一个栈结构：每遇到一个 defer，就压入栈顶；函数返回时，从栈顶开始依次弹出执行。

所以口诀只有四个字：后进先出。

go
func main() {
    defer fmt.Println("A")  // 栈底
    defer fmt.Println("B")  // 栈中
    defer fmt.Println("C")  // 栈顶 → 最先执行
}
// 输出：C B A

这不是 bug，是设计使然。

---

一、参数求值时机：90% 的人在这里翻车

这是最隐蔽、最高频的坑：

defer 的参数，在 defer 语句出现的那一刻就求值完毕，不是等到执行时才取。

go
i := 0
defer fmt.Println(i)  // 打印 0，不是 1
i++

而闭包引用则完全不同------它捕获的是变量本身，执行时才取值：

go
i := 0
defer func() { fmt.Println(i) }()  // 打印 1！
i++

函数参数 = 快照，闭包引用 = 实时。 这条分界线，踩过一次就不会再忘。

---

二、return 不是原子操作：defer 能"截胡"返回值

return 实际上分两步：

1. 先把返回值写入返回变量（命名返回值此时已存在）
2. 再执行 defer 栈
3. 最后才真正返回

这意味着：只有命名返回值能被 defer 修改，匿名返回值不行。

go
// ✅ 命名返回值 → defer 能改
func f() (x int) {
    defer func() { x += 10 }()
    return 5  // 返回 15
}

// ❌ 匿名返回值 → defer 改的是局部变量，不影响返回值
func g() int {
    x := 5
    defer func() { x += 10 }()
    return x  // 返回 5
}

多个 defer 修改同一个命名返回值？后面的覆盖前面的------因为后进先出。

---

三、底层实现：三种 defer，性能天差地别

Go 编译器根据场景自动选择三种实现方式，理解它们才能写出高性能代码：

方式	版本引入	触发条件	性能
堆分配 defer	Go 1.12 之前	全部	最差，每次堆分配
栈分配 defer	Go 1.13	普通场景	提升约 30%，无堆分配
开放编码 defer	Go 1.14	defer ≤ 8 个、无循环、返回值×defer 数 ≤ 15	近乎零成本，直接内联展开

底层数据结构是 _defer 链表，挂在当前 Goroutine 的 g._defer 指针上：

go
type _defer struct {
    link *_defer     // 链表指针，指向下一个 defer
    fn   func()      // 要调用的函数
    // ...
}

每次 deferproc 调用，就是把新节点头插到链表：

go
d.link = gp._defer
gp._defer = d

函数返回时，deferreturn 从链表头依次取出执行------这就是 LIFO 的来源。

---

四、panic 时 defer 照样执行，但有严格规则

panic 发生后，不会立即退出，而是先走完 defer 栈，再向上传播。

go
func A() {
    defer fmt.Println("A 的 defer")
    panic("炸了")
    defer fmt.Println("这行不会注册")  // panic 之后的代码不执行
}
// 输出：A 的 defer → panic: 炸了

recover 必须写在 defer 内部，且只能捕获当前 Goroutine 的 panic。 写在外面？永远返回 nil。

go
// ✅ 正确
defer func() {
    if r := recover(); r != nil {
        fmt.Println("救回来了:", r)
    }
}()

// ❌ 错误：recover 在 defer 外面，永远收不到
if r := recover(); r != nil { ... }

---

五、五个经典翻车现场

1. 循环里 defer → 资源堆积

go
for _, f := range files {
    f, _ := os.Open(f)
    defer f.Close()  // ❌ 所有 Close 推到函数结束才执行
}

修复：把 defer 放进单独函数，让它在每次迭代结束时立刻生效：

go
for _, f := range files {
    go func(path string) {
        f, _ := os.Open(path)
        defer f.Close()  // ✅ 立即生效
        // ...
    }(f)
}

2. 循环变量捕获 → 全输出最后的值

go
for i := 0; i < 3; i++ {
    go func() { fmt.Println(i) }()  // 输出：3 3 3
}

修复：传参或局部拷贝：

go
for i := 0; i < 3; i++ {
    go func(v int) { fmt.Println(v) }(i)  // 输出：0 1 2
}

3. defer 闭包看不到最新值

go
start := time.Now()
defer func() {
    fmt.Println(time.Since(start))  // 几乎为 0，因为 start 在 defer 时已快照
}()
time.Sleep(time.Second)

想看到真实耗时？用参数传进去，或者直接在 defer 里写表达式（但要注意求值时机）。

4. os.Exit 直接杀进程，defer 全白写

go
defer f.Close()
os.Exit(1)  // ❌ defer 不会执行

永远不要在 defer 里放关键清理逻辑然后用 os.Exit 退出。

5. 嵌套 defer 的执行顺序

go
func A() {
    defer A1()
    defer B()
    defer A2()
}
func B() {
    defer B1()
    defer B2()
}
// 执行顺序：A2 → B2 → B1 → A1

链表视角：A2 → B2 → B1 → A1，谁后注册谁先跑。

---

速查表

问题	答案
defer 按什么顺序执行？	后进先出（LIFO）
参数什么时候求值？	defer 语句出现时，不是执行时
能修改返回值吗？	只有名命名返回值可以
panic 后 defer 执行吗？	执行，recover 必须在 defer 内
循环里能用 defer 吗？	能，但要封装成函数让它及时生效
os.Exit 后 defer 执行吗？	不执行
底层数据结构？	_defer 链表，头插法注册
最佳性能实现？	Go 1.14+ 开放编码，近乎零成本

---

defer 看起来简单，实则暗藏五层机制：栈顺序、参数快照、返回值拦截、panic 协同、三种编译实现。大多数 bug 不是因为不会写 defer，而是以为自己懂了。

记住：defer 注册的是那一刻的世界快照 ，执行的是函数退出前的最后时刻。这两个时间点之间的差距，就是所有坑的来源。