Go defer、recover、panic 与函数调用栈

学习目标

学完本章后，你将具备以下能力：

1. 能够准确描述 defer 的注册时机与执行时机，并用 LIFO 规则预测多个 defer 的执行顺序。
2. 能够区分 defer 参数立即求值与闭包延迟求值的行为差异，写出不会踩坑的资源释放代码。
3. 能够解释命名返回值与匿名返回值在 defer 修改返回值时的不同表现。
4. 能够手写 panic/recover 的完整恢复模板，并说明跨 goroutine panic 为何无法被父 goroutine 捕获。
5. 能够画出函数调用栈帧的结构布局，解释 goroutine 栈的扩容机制与初始栈大小。

前置知识： 了解 Go 基本语法（函数定义、变量声明、goroutine、channel），知道"栈"是一种后进先出的数据结构。

动手做 3 件事：

• 在本地创建一个 .go 文件，写 3 个 defer 打印语句，运行后观察输出顺序是否符合 LIFO。
• 故意写一个 panic("boom")，用 defer + recover 捕获它，确认程序不会崩溃。
• 用 runtime.Stack 打印当前 goroutine 的调用栈，数一数有多少层函数调用。

一、defer 执行机制

1.1 用生活类比先建立直觉

想象快递柜的场景：你一天里陆续往柜子里放包裹——上午放了一个，中午放了一个，下午又放了一个。取件的时候，快递柜系统总是让你先取最后放进来的那个，这就是"后进先出"（LIFO）。

Go 的 defer 机制就是快递柜：你用 defer 注册一个"延迟任务"，它不会立刻执行，而是被压入当前函数的 defer 栈。等函数即将返回时，这些任务按后进先出的顺序依次弹出执行。

graph TD
    A[函数开始执行] --> B[defer 注册任务1]
    B --> C[defer 注册任务2]
    C --> D[defer 注册任务3]
    D --> E[函数即将返回]
    E --> F[执行任务3]
    F --> G[执行任务2]
    G --> H[执行任务1]
    H --> I[函数真正返回]

桥接： 快递柜的"后放先取"对应 defer 的 LIFO 执行栈。关键在于区分两个时刻——注册时刻（放包裹）和执行时刻（取包裹）。defer 在注册时刻只做一件事：把函数和它的参数打包成一个"任务记录"压入栈中，真正的执行发生在函数返回前。

1.2 工程要点

知识点 1 & 2 & 6：defer 注册时机、LIFO 顺序与 defer 的优势

defer 的核心规则：

• 注册时机：defer 语句被执行到的那一刻注册，不是编译时。
• 执行时机：在所在函数返回前（无论是正常 return 还是 panic），按 LIFO 顺序执行。
• 优势：资源释放（文件、锁、数据库连接）、panic 恢复、代码就近放置（open 旁边写 close，避免遗忘）。

package main

import "fmt"

func main() {
    // 步骤1：注册第一个defer，最后执行
    defer fmt.Println("第一个defer注册（最后执行）")

    // 步骤2：注册第二个defer，倒数第二执行
    defer fmt.Println("第二个defer注册（倒数第二执行）")

    // 步骤3：注册第三个defer，最先执行
    defer fmt.Println("第三个defer注册（最先执行）")

    fmt.Println("函数体正常执行")
}

输出：

函数体正常执行
第三个defer注册（最先执行）
第二个defer注册（倒数第二执行）
第一个defer注册（最后执行）

defer 的典型应用场景对比：

package main

import (
    "fmt"
    "os"
)

func readFile() error {
    // 步骤1：打开文件
    f, err := os.Open("test.txt")
    if err != nil {
        return err
    }

    // 步骤2：紧跟Open注册defer Close，确保任何路径都关闭
    defer func() {
        // 步骤3：关闭文件并检查错误
        if cerr := f.Close(); cerr != nil {
            fmt.Println("关闭文件失败:", cerr)
        }
    }()

    // 步骤4：读取数据（即使这里panic，defer仍会执行）
    buf := make([]byte, 1024)
    _, err = f.Read(buf)
    if err != nil {
        return err
    }

    fmt.Println("读取到:", string(buf))
    return nil
}

⚠️ 新手必踩的坑： defer 只在所在函数返回时执行。如果你在循环里写 defer，所有 defer 会堆积到函数结束才执行，可能导致资源迟迟不释放。如果必须在循环中释放资源，要么把循环体抽成独立函数，要么用显式 Close 代替 defer。

知识点 6 补充：defer 不是免费的。 每个 defer 注册会分配一个 _defer 结构体（在 Go 1.14 之后编译器对简单 defer 做了开放编码优化，开销几乎为零，但仍建议不要在热路径中滥用）。

二、defer 参数求值与闭包

2.1 用生活类比先建立直觉

这里有两种"记录"方式，对应 defer 的两种求值行为：

• 拍照定格（参数立即求值）：你在上午 10 点拍了一张照片，照片里时钟显示 10:00。到了下午 3 点再看这张照片，它仍然是 10:00——拍照那一刻时间就"定格"了。
• 录像跟随（闭包延迟求值）：你架了一台摄像机对准时钟，回放时看到的是播放时刻的时间，而不是架设摄像机时的时间。

defer 对直接传参的行为像拍照——参数在 defer 注册时就被求值并定格；对闭包捕获变量的行为像录像——变量的值推迟到 defer 真正执行时才读取。

graph LR
    subgraph A [参数立即求值：拍照定格]
        A1[注册defer时
i=0] --> A2[定格值0存入任务]
        A2 --> A3[循环结束 i=3]
        A3 --> A4[执行时仍打印0]
    end
    subgraph B [闭包延迟求值：录像跟随]
        B1[注册defer时
捕获i的引用] --> B2[循环结束 i=3]
        B2 --> B3[执行时读取i
打印3]
    end

桥接： “拍照定格"对应值传递——defer 把参数值复制一份存起来；“录像跟随"对应引用捕获——闭包持有变量的地址，到执行时才去解引用。理解这个区别，你就掌握了 defer 面试题的核心。

2.2 工程要点

知识点 3：defer 参数立即求值

package main

import "fmt"

func main() {
    i := 0

    // 步骤1：defer注册时，参数i立即求值为0，存入定格值
    defer fmt.Println("立即求值，i =", i)

    // 步骤2：修改变量，但定格值不变
    i = 100
    fmt.Println("当前i =", i)
}

输出：

当前i = 100
立即求值，i = 0

知识点 4：defer 与闭包（延迟求值）

package main

import "fmt"

func main() {
    for i := 0; i < 3; i++ {
        // 步骤1：闭包捕获i的引用，不立即求值
        defer func() {
            fmt.Println("闭包延迟求值，i =", i)
        }()
    }
}

输出：

闭包延迟求值，i = 3
闭包延迟求值，i = 3
闭包延迟求值，i = 3

为什么全是 3？因为闭包捕获的是 i 的引用，循环结束后 i 已经变成 3，三个 defer 执行时读到的都是 3。

修复方法：每次循环传入参数副本。

package main

import "fmt"

func main() {
    for i := 0; i < 3; i++ {
        // 步骤1：通过参数传入，立即求值为当前i值
        defer func(val int) {
            fmt.Println("修复后，val =", val)
        }(i)
    }
}

输出：

修复后，val = 2
修复后，val = 1
修复后，val = 0

⚠️ 新手必踩的坑： 在循环中使用 defer + 闭包是最经典的陷阱。如果闭包捕获了循环变量，所有 defer 执行时都会读到循环结束后的最终值。记住规则——要定格就传参，要跟随就用闭包。

立即求值 vs 闭包延迟求值对比表：

三、defer 修改返回值

3.1 用生活类比先建立直觉

想象你在网上下单退货：

• 命名返回值好比"订单上写了收件人姓名”——快递员（defer）可以在发货前修改订单上的姓名，最终寄出去的是修改后的名字。
• 匿名返回值好比"你直接把商品拿走了”——商品已经离手，defer 再想改也改不了，因为它操作的是一个已经不存在的临时值。

graph TD
    subgraph A [命名返回值：可被defer修改]
        A1[函数声明命名返回值 r] --> A2[函数体执行]
        A2 --> A3[defer执行
修改r的值]
        A3 --> A4[返回r的最终值]
    end
    subgraph B [匿名返回值：不可被defer修改]
        B1[函数体计算返回值] --> B2[返回值存入临时变量]
        B2 --> B3[defer执行
无法访问临时变量]
        B3 --> B4[返回原始值]
    end

桥接： 关键在于返回值是否有"名字"。命名返回值在函数作用域内是一个真实存在的变量，defer 可以通过名字找到它并修改；匿名返回值在赋值给调用方后就"匿名"了，defer 拿不到引用，自然无法修改。

3.2 工程要点

知识点 5：命名返回值 vs 匿名返回值

package main

import "fmt"

// 命名返回值：result 是一个真实变量，defer 可以修改它
func namedReturn() (result int) {
    // 步骤1：result被初始化为零值0
    result = 1

    // 步骤2：defer通过命名返回值修改result
    defer func() {
        result = 999
    }()

    // 步骤3：return将result的值返回，但defer在返回前执行
    return result
}

// 匿名返回值：返回值没有名字，defer 无法修改
func anonymousReturn() int {
    // 步骤1：计算返回值
    val := 1

    // 步骤2：defer无法访问匿名返回值
    defer func() {
        val = 999
    }()

    // 步骤3：return把val的值拷贝给返回值后，defer再改val已无效
    return val
}

func main() {
    fmt.Println("命名返回值:", namedReturn())       // 999
    fmt.Println("匿名返回值:", anonymousReturn())   // 1
}

输出：

命名返回值: 999
匿名返回值: 1

⚠️ 新手必踩的坑： 这个行为经常让人困惑——同样的 return val，为什么一个被改了一个没被改？答案是：Go 的 return 语句分为两步——先给返回值赋值，再执行 defer，最后真正返回。命名返回值有名字，defer 能找到它；匿名返回值在赋值那一刻是"临时的"，defer 摸不到。

return 的三步执行模型：

四、panic 与 recover 机制

4.1 用生活类比先建立直觉

把 panic 想象成大楼里的火警警报：

• 警报一响（panic 触发），当前楼层（当前函数）的作业立即中断。
• 警报沿着楼层向上传播（沿调用栈向上），每一层都有机会停下来处理。
• 每层楼如果安排了安全员（defer + recover），安全员可以按停警报（recover），大楼恢复正常运转。
• 但如果每一层都没有安全员，警报传到顶层（最外层），整栋楼疏散（程序崩溃）。

graph TD
    A[函数A调用函数B] --> B[函数B调用函数C]
    B --> C[函数C触发panic]
    C --> D[函数C的defer执行]
    D --> E{有recover吗}
    E -->|有| F[recover捕获panic
函数C正常返回]
    E -->|无| G[panic传播到函数B]
    G --> H[函数B的defer执行]
    H --> I{有recover吗}
    I -->|有| J[recover捕获panic
函数B正常返回]
    I -->|无| K[panic传播到函数A]
    K --> L[无人捕获
程序崩溃]

桥接： “火警向上传播"对应 panic 沿调用栈向上展开，每一层的 defer 都会执行（这很重要——panic 时 defer 一定会执行，这就是资源释放的保障）。“安全员按停警报"对应 recover——它只能在 defer 函数中调用，一旦调用成功，panic 就被"消化"了，当前函数可以正常返回。

4.2 工程要点

知识点 7：recover 的使用规则

recover 有三条铁律：

1. 必须在 defer 函数中调用——直接调用 recover 返回 nil，无效。
2. 只对当前 goroutine 有效——无法跨 goroutine 捕获 panic。
3. recover 后程序继续执行——panic 被消化，调用链恢复正常。

package main

import "fmt"

// 完整的 recover 模板
func safeRun(name string, fn func()) {
    // 步骤1：在defer中调用recover
    defer func() {
        // 步骤2：recover返回panic的值，nil表示没有panic
        if r := recover(); r != nil {
            fmt.Printf("[%s] 捕获到panic: %v\n", name, r)
        }
    }()

    // 步骤3：执行可能有panic的函数
    fn()
}

func riskyOperation() {
    // 步骤4：故意触发panic
    panic("数据库连接失败")
}

func main() {
    safeRun("数据库操作", riskyOperation)
    fmt.Println("程序继续运行，没有崩溃")
}

输出：

[数据库操作] 捕获到panic: 数据库连接失败
程序继续运行，没有崩溃

知识点 8：panic 传播与跨 goroutine 无效

package main

import (
    "fmt"
    "time"
)

func main() {
    // 步骤1：父goroutine注册recover
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("父goroutine捕获:", r)
        }
    }()

    // 步骤2：启动子goroutine
    go func() {
        // 步骤3：子goroutine触发panic
        // 注意：父goroutine的recover无法捕获这个panic！
        panic("子goroutine崩溃")
    }()

    // 步骤4：等待子goroutine崩溃
    time.Sleep(time.Second)
    fmt.Println("这行不会执行")
}

⚠️ 新手必踩的坑： 子 goroutine 的 panic 无法被父 goroutine 的 recover 捕获！这是因为每个 goroutine 有独立的调用栈，panic 只在自己所在 goroutine 的栈上传播。子 goroutine panic 如果没有自己内部的 recover，会直接导致整个程序崩溃。正确做法：在每个 goroutine 入口都注册 recover。

panic 传播规则总结表：

五、函数调用栈

5.1 用生活类比先建立直觉

把函数调用栈想象成一栋办公楼：

• 每调用一个函数，就在桌上叠一个文件夹（栈帧），最底下的文件夹是最早调用的函数（如 main），最上面是当前正在执行的函数。
• 每个文件夹里装着这个函数的"工作材料”：参数、局部变量、返回值草稿、以及一张"做完后回到哪一页"的便签（返回地址）。
• 函数执行完，最上面的文件夹被拿走（栈帧销毁），你回到下面那个文件夹，翻到便签上记的页码继续工作。

graph TD
    subgraph 栈帧从高地址到低地址
        S1[main函数栈帧
局部变量 返回地址]
        S1 --> S2[funcA栈帧
参数 局部变量 返回地址]
        S2 --> S3[funcB栈帧
参数 局部变量 返回地址]
        S3 --> S4[funcC栈帧
当前正在执行
参数 局部变量 返回地址]
    end

桥接： “叠文件夹"就是压栈，“拿走文件夹"就是出栈。每个文件夹（栈帧）内部有一块区域专门存放局部变量、参数、返回值和返回地址。理解栈帧的结构，就能理解为什么局部变量在函数返回后失效——文件夹被拿走了，材料也一并销毁。

5.2 工程要点

知识点 9：函数调用的完整过程

一次函数调用的步骤：

1. 参数入栈：调用者把参数压入栈中（或通过寄存器传递）。
2. 返回地址入栈：CPU 把"调用完下一条指令的地址"压栈，以便函数返回时知道回哪里。
3. 栈帧建立：被调函数保存上一帧的基址指针（BP），设置自己的 BP，分配局部变量空间。
4. 执行函数体：在栈帧内读写局部变量、做计算。
5. 返回值写入：把返回值写入约定位置（寄存器或栈帧）。
6. 栈帧销毁：恢复 BP，回收局部变量空间。
7. 返回：根据返回地址跳转回调用者，继续执行。

package main

import "fmt"

// 演示调用栈层级
func level3() int {
    // 步骤1：最深层函数，返回42
    return 42
}

func level2() int {
    // 步骤2：调用level3，等它返回后加1
    val := level3()
    return val + 1
}

func level1() int {
    // 步骤3：调用level2，等它返回后乘以2
    val := level2()
    return val * 2
}

func main() {
    // 步骤4：调用level1，栈深度达到4层（main→level1→level2→level3）
    result := level1()
    fmt.Println("最终结果:", result) // (42 + 1) * 2 = 86
}

知识点 10：栈帧里面有什么

每个栈帧包含以下内容：

graph TD
    subgraph 栈帧内部布局
        F1[返回地址
函数结束后跳回哪里]
        F1 --> F2[上一帧基址指针 BP
用于恢复调用者栈帧]
        F2 --> F3[函数参数
调用者传入的值]
        F3 --> F4[局部变量
函数内部声明的变量]
        F4 --> F5[返回值空间
存放计算结果]
    end

栈帧内容说明表：

⚠️ 新手必踩的坑： 函数返回后，栈帧被销毁，局部变量的内存空间被回收。如果你返回了局部变量的指针，在 Go 中这是安全的（因为逃逸分析会把它分配到堆上），但在 C/C++ 中这是悬垂指针 bug。Go 的编译器会自动做逃逸分析，帮你处理这个问题。

六、goroutine 栈管理

6.1 用生活类比先建立直觉

把 goroutine 栈想象成一张可伸缩的办公桌：

• 系统线程的栈好比一张固定大小的大桌子（通常 1~8 MB），不管你用不用得了这么多空间，一开工就占这么多。
• goroutine 的栈好比一张可伸缩的小桌子：一开始只有 2 KB（一张笔记本大小），你东西放不下了，桌子自动变长；东西少了，桌子也可以缩回去。

这种"按需伸缩"的设计让 Go 可以轻松创建几十万个 goroutine，而系统线程创建几千个就吃力了。

graph LR
    subgraph A [初始状态：2KB]
        A1[goroutine启动] --> A2[初始栈2KB]
    end
    subgraph B [扩容：不够用了]
        B1[检测到栈空间不足] --> B2[分配新栈
通常翻倍]
        B2 --> B3[拷贝旧栈内容]
        B3 --> B4[更新所有栈指针]
    end
    subgraph C [最大限制：1GB]
        C1[栈持续增长] --> C2{超过1GB}
        C2 -->|是| C3[触发栈溢出panic]
    end

桥接： “伸缩桌子"对应 goroutine 栈的动态扩容机制。关键在于"拷贝”——新桌子不是原地变大的，而是找一张更大的新桌子，把旧桌子上的东西全部搬过去，然后通知所有人"地址变了”。这要求 Go runtime 能追踪所有指向栈的指针并更新它们。

6.2 工程要点

知识点 11 & 12：goroutine 栈的初始大小、扩容与收缩

栈扩容的详细过程：

1. 编译器在每个函数序言（prologue）中插入栈空间检测代码。
2. 当前栈剩余空间不足时，触发 runtime 的 morestack。
3. runtime 分配一块更大的新栈（通常是原来的 2 倍）。
4. 把旧栈内容逐字节拷贝到新栈。
5. 遍历所有指向旧栈的指针，重定向到新栈地址。
6. 释放旧栈，goroutine 在新栈上继续执行。

package main

import (
    "fmt"
    "runtime"
)

// 演示递归导致的栈增长
func deepRecurse(n int) int {
    // 步骤1：递归基线
    if n <= 0 {
        return 0
    }
    // 步骤2：每层分配局部变量，消耗栈空间
    var buf [1024]byte
    buf[0] = byte(n)
    // 步骤3：递归调用，栈深度增加
    return int(buf[0]) + deepRecurse(n-1)
}

func main() {
    // 步骤4：获取初始栈大小
    var memStats runtime.MemStats
    runtime.ReadMemStats(&memStats)
    fmt.Printf("递归前: Goroutine数量=%d\n", runtime.NumGoroutine())

    // 步骤5：深度递归会触发栈扩容
    result := deepRecurse(10000)
    fmt.Println("递归结果:", result)
}

⚠️ 新手必踩的坑： 无限递归是导致 goroutine 栈溢出（超过 1 GB）的最常见原因。Go 会在栈超出 1 GB 限制时触发 panic（stack overflow），这个 panic 无法被 recover 捕获，程序会直接崩溃。写递归时一定要确保有正确的终止条件。

栈收缩： 除了扩容，Go runtime 还会在 GC 时检测：如果一个 goroutine 的栈使用量远小于当前分配量，runtime 会把它收缩到更小的栈（同样需要拷贝），以节省内存。这个过程对程序员完全透明。

七、select 底层机制

7.1 用生活类比先建立直觉

想象一个银行大厅有多个业务窗口（多个 channel case），你站在中间等待：

• 哪个窗口先空出来（哪个 channel 先就绪），你就去哪个窗口办理。
• 如果多个窗口同时空出来，你随机选一个（Go 的 select 不是按顺序，而是随机选择）。
• 如果所有窗口都满员，而你又没设"放弃等待"的 default 分支，你就一直等下去（阻塞）。
• 如果某个窗口贴了"暂停服务"的牌子（nil channel），那个窗口永远不会被选中。

graph TD
    A[select语句] --> B{有case就绪吗}
    B -->|多个就绪| C[随机选一个执行]
    B -->|只有一个就绪| D[执行那个case]
    B -->|无case就绪| E{有default吗}
    E -->|有| F[执行default分支]
    E -->|无| G[阻塞等待
直到有case就绪]
    C --> H[执行对应分支]
    D --> H

桥接： “多个窗口随机选"对应 select 的随机选择算法；“贴暂停服务的窗口"对应 nil channel 永不就绪；“没有 default 就一直等"对应无 default 时的阻塞行为。select 底层用 lockorder（对 case 涉及的 channel 排序加锁）来避免死锁。

7.2 工程要点

知识点 13：select 底层 4 个关键点（简略，详见并发章节）

package main

import (
    "fmt"
    "time"
)

func main() {
    ch1 := make(chan string)
    ch2 := make(chan string)

    // 步骤1：启动发送者
    go func() {
        time.Sleep(10 * time.Millisecond)
        ch1 <- "来自ch1"
    }()
    go func() {
        time.Sleep(10 * time.Millisecond)
        ch2 <- "来自ch2"
    }()

    // 步骤2：select随机选择就绪的case
    select {
    case msg := <-ch1:
        fmt.Println("收到:", msg)
    case msg := <-ch2:
        fmt.Println("收到:", msg)
    }
}

select 底层 4 个关键点：

package main

import "fmt"

func main() {
    // 步骤1：nil channel演示
    var nilCh chan int   // nil channel

    select {
    case <-nilCh:
        // 步骤2：这行永远不会执行，nil channel永不就绪
        fmt.Println("不会执行")
    default:
        // 步骤3：因为没有就绪的case，执行default
        fmt.Println(nilCh)
    }
}

⚠️ 新手必踩的坑： 如果你把一个 channel 设为 nil 来"禁用"某个 case，要确保 select 中有其他可用的 case 或 default，否则 select 会因为没有任何 case 能就绪而永久阻塞。nil channel 的设计用途是：在 select 中动态控制某个 case 是否参与选择——设为 nil 就等于"临时摘掉这个窗口”。

八、栈帧里的寄存器与 defer 链表

8.1 用生活类比先建立直觉

前面讲到栈帧里装着参数、局部变量、返回值、返回地址和 BP。还有两类"看不见的工作人员"值得专门讲清楚：

• 寄存器（SP / BP / PC） 好比办公桌旁的三件随身工具：

  • SP（栈指针 Stack Pointer） 像一支"当前写到哪一页"的荧光笔，永远指向栈顶（当前栈帧的顶部边界）。
  • BP（基址指针 Base Pointer） 像书签，夹在当前这一叠文件夹的封面上，标记"我现在在哪一层工作”。
  • PC（程序计数器 Program Counter） 像大脑里正在朗读的那行字，指向下一条要执行的指令；函数返回时用的"返回地址"其实就是 PC 被记录下来的那个值。

• _defer 链表 好比公司前台挂的一串"待办挂牌”：每注册一个 defer，就在挂牌链最前面挂一个新牌（头插法）；函数要走了，前台就从最前面的牌子开始，挨个取下来执行，先取到的后挂的，正是 LIFO。

graph TD
    subgraph 寄存器与栈帧
        R1[SP 栈指针
指向栈顶边界]
        R1 --> R2[BP 基址指针
标记当前帧位置]
        R2 --> R3[PC 程序计数器
指向当前指令
返回地址=PC当时的值]
    end
    subgraph defer链表头插法
        D1[注册defer C 表头]
        D1 --> D2[注册defer B]
        D2 --> D3[注册defer A]
        D3 --> D4[g._defer=nil]
    end

桥接： 寄存器是 CPU 的"临时工作台”，函数调用时 SP 移动、BP 入栈保存、PC 的当前值被压栈成为返回地址；而 defer 链表挂在当前 goroutine 的 g 结构体上，用头插法记录 defer 任务。两者一起，才让"函数返回前按 LIFO 执行 defer"成为可能。

8.2 工程要点

知识点 10 补充：寄存器在调用过程中的角色

调用一个函数、建立栈帧时，CPU 寄存器的动作是：

1. SP 下移：为新的栈帧腾出空间（栈通常向低地址增长）。
2. BP 入栈：把调用者的 BP 保存到新栈帧，再把 BP 指向新帧起点（这样函数内部用 BP+偏移 就能稳定定位参数和局部变量）。
3. 返回地址入栈：PC 当前值（下一条指令地址）被压栈，成为栈帧里的"返回地址"字段。
4. PC 跳转：跳到被调函数的入口指令。
5. 返回时：弹出返回地址装入 PC，恢复 BP、SP，回到调用者继续往下执行。

⚠️ 新手必踩的坑： 不要把"寄存器"和"栈帧里的字段"混为一谈。返回地址被压进了栈（所以它是栈帧的一部分，可被回收）；而 SP/BP/PC 是 CPU 寄存器，不属于某个栈帧，但 BP 的旧值会被保存到栈帧里以便恢复。defer 的 _defer 节点本身分配在堆上（由 runtime 管理），只是通过 g._defer 指针串成链表，并不占用栈帧空间。

_defer 链表与 LIFO 的关系

每个 goroutine 在 runtime 里对应一个 g 结构体，其中 g._defer 指向该 goroutine 的 defer 链表头。执行 defer f() 时，runtime 分配一个 _defer 节点，用头插法挂到 g._defer 头部。函数返回前，runtime 从链表头开始逐个取出执行——因为后进的节点在表头，所以"后注册先执行"，完美对应 LIFO。

package main

import (
	"fmt"
	"runtime"
)

// 演示：连续注册 defer 对应链表头插法（LIFO 的底层来源）
func demoDeferList() {
	// 步骤1：连续注册3个defer（头插法入链表，C 在最表头）
	defer fmt.Println("defer A（最先注册，最后执行）")
	defer fmt.Println("defer B")
	defer fmt.Println("defer C（最后注册，最先执行）")

	// 步骤2：打印当前 goroutine 栈，间接印证与调用栈的关系
	buf := make([]byte, 1024)
	_ = runtime.Stack(buf, false)
	fmt.Println("函数体执行中...")
}

func main() {
	demoDeferList()
	// 输出顺序：C、B、A（LIFO，正是链表头插法的体现）
}

栈帧内容 + 寄存器 + defer 链表 全景表：

九、WaitGroup：并发等待多个协程结束

9.1 用生活类比先建立直觉

并发编程里最常见的需求之一：主 goroutine 要等所有"干活"的 goroutine 都干完再收工。这就像幼儿园老师放学的点名：

• 放学前，老师先在花名册上记下有 N 个小朋友要接送（对应 Add(N) 增加计数）。
• 每个小朋友到家，家长在群里报"到了"（对应 Done()，计数减 1）。
• 老师站在门口 Wait()，只要名册上还有人没到，就一直等着；等最后一个报到、计数归零，老师才锁门下班。

如果少了 Add 或 Done，就会出现"老师提前锁门"或"老师永远等不到人"的 bug。

sequenceDiagram
    participant M as 主goroutine
    participant W as WaitGroup
    participant G1 as 子goroutine1
    participant G2 as 子goroutine2
    M->>W: Add(2)
    M->>G1: go 干活
    M->>G2: go 干活
    M->>W: Wait() 阻塞
    G1->>W: Done() 计数2->1
    G2->>W: Done() 计数1->0
    W-->>M: 计数归零 唤醒
    M->>M: 继续执行

桥接： “花名册计数"对应 WaitGroup 内部的 counter；“老师站在门口"对应 Wait() 在计数 > 0 时通过信号量 sema 挂起；“最后一个报到唤醒老师"对应 Done() 把计数减到 0 时 semrelease 唤醒所有等待者。

9.2 工程要点

知识点：WaitGroup 的三个方法

底层结构（简化）： WaitGroup 内部有三个关键字段：counter（还在跑的 goroutine 数）、waiter（正在 Wait 阻塞的 goroutine 数）、sema（信号量，用于阻塞/唤醒）。

package main

import (
	"fmt"
	"sync"
	"time"
)

// 使用 WaitGroup 等待多个协程结束
func main() {
	// 步骤1：声明WaitGroup
	var wg sync.WaitGroup

	// 步骤2：Add(3) 登记要等待3个goroutine
	wg.Add(3)

	// 步骤3：启动3个干活协程，每个结束后Done
	for i := 1; i <= 3; i++ {
		go func(id int) {
			defer wg.Done() // 步骤4：结束时计数减1
			time.Sleep(time.Millisecond * time.Duration(id) * 100)
			fmt.Printf("协程 %d 干完活了\n", id)
		}(i)
	}

	// 步骤5：主goroutine阻塞，直到3个都Done
	wg.Wait()
	fmt.Println("全部协程结束，主goroutine收工")
}

Add 与 Wait 的底层执行流程：

1. Add(n)：原子地把 n 加到 counter。若加之后 counter 归零且存在 waiter，则释放信号量唤醒所有等待者；若加之前为 0、加之后 > 0，则重新"开门营业”。
2. Wait()：原子读 counter，若 > 0，则 waiter++ 并通过 semacquire 把当前 goroutine 挂起（进入等待队列）；被唤醒后再检查计数。
3. Done()：等价于 Add(-1)；当 counter 减到 0，runtime 调用 semrelease 唤醒全部 waiter。

⚠️ 新手必踩的坑：

• Add 必须在 go 启动协程之前调用，或保证在所有 Done 之前完成。如果先启动协程、协程里先 Done 把计数减到 0，主协程的 Wait 可能永远等不到（甚至 panic “negative WaitGroup counter”）。
• WaitGroup 不能被复制：它内部含 noCopy 标记，值拷贝会让两个 WaitGroup 各自计数、等待失效。要传就传指针 &wg。
• Add 的 delta 不能超过当前 counter 的负值，否则触发 panic("sync: negative WaitGroup counter")。

十、recover 必须"对的人、对的栈”：同 goroutine 才救得了

对应《Go 进阶实战 100 题》问题 13。这一题把"recover 无效"的几个原因凑齐了：defer 注册在别的 goroutine、且注册 defer 的函数是个永不返回的 for{} 循环、panic 又来自类型断言失败。

10.1 用生活类比先建立直觉

recover 像一间屋子里准备的灭火器：火（panic）在哪一间屋子烧起来，灭火器就必须放在那一间屋子里。如果你把灭火器放在隔壁房间（另一个 goroutine 的 defer 里），本房间的火烧起来时，隔壁那瓶根本够不着。

另一个陷阱是”永远不下班的人不用打卡"：defer 好比"下班打卡"，只有函数真正下班（返回）的那一刻才打卡。如果函数在 for{} 里无限上班、永不返回，那张卡永远打不上——defer 永远不会执行。

这两个坑叠加起来，就是问题 13 里 defer p.deferError() 为什么完全没用的根本原因。

sequenceDiagram
    participant Main as main 协程
    participant Run as run 协程(defer recover)
    participant Exec as exec 协程(类型断言)
    Main->>Run: go p.run(a)
    Run->>Exec: go p.exec(a)
    Main->>Run: a <- "1"（字符串）
    Run-->>Exec: 通道把 "1" 传给 exec
    Exec->>Exec: m := msg.(int) 把字符串断言成 int
    Exec--xExec: panic！本协程没有 recover
    Note over Exec: 整型程序崩溃
    Note over Run: run 的 defer 在别的协程
而且 run 永不返回，救不了

桥接： “灭火器放错房间"对应 recover 和 panic 不在同一个 goroutine；“不下班不打卡"对应 defer 所在函数永不返回。两者任一成立，recover 都抓不到 panic。

10.2 工程要点

知识点：recover 生效的两个硬前提

1. 同栈（同 goroutine）：recover 只能消化当前 goroutine 调用栈上的 panic。别的 goroutine 的 panic，哪怕你父 goroutine 写了 defer recover，也救不了。
2. 能返回：recover 写在 defer 里，而 defer 只有在所在函数返回时才执行。函数若卡在 for{} 永不返回，defer 永远没机会跑。

package main

import (
	"fmt"
	"time"
)

type Project struct{}

// 放错位置的 recover：它在 run 协程，但 panic 在 exec 协程
func (p *Project) deferError() {
	if err := recover(); err != nil {
		fmt.Println("recover: ", err)
	}
}

func (p *Project) exec(msgchan chan interface{}) {
	// 步骤1：exec 在独立 goroutine 中运行，自身没有 defer recover
	// 收到字符串却断言成 int，必然 panic
	for msg := range msgchan {
		m := msg.(int) // 类型断言失败会 panic，本协程无人接住
		fmt.Println("msg: ", m)
	}
}

func (p *Project) run(msgchan chan interface{}) {
	for {
		// 步骤2：defer 注册在 run 协程
		// 但 run 是无限循环永不返回，这个 defer 永远没有执行机会
		// 更何况 panic 发生在 exec 协程，run 的 recover 也够不着
		defer p.deferError()
		go p.exec(msgchan)
		time.Sleep(time.Second * 2)
	}
}

func main() {
	p := new(Project)
	a := make(chan interface{}, 100)
	go p.run(a)
	// 步骤3：往 interface{} 通道塞字符串 "1"
	a <- "1"
	time.Sleep(time.Second * 2) // 到这里 exec 已 panic，程序崩溃
}

上面这段会崩溃，崩溃点在 exec 协程的 m := msg.(int)——字符串 "1" 无法断言成 int，且 exec 内部没有 recover。父层 run / main 的 recover 都救不了。

正确示范：把 recover 放进真正会 panic 的那个 goroutine。

package main

import (
	"fmt"
	"time"
)

// 正确：recover 就在会 panic 的同一个 goroutine 内部
func safeExec(msgchan chan interface{}) {
	// 步骤1：defer + recover 注册在 safeExec 自己的协程里
	defer func() {
		if err := recover(); err != nil {
			fmt.Println("在本协程内捕获 panic: ", err)
		}
	}()
	for msg := range msgchan {
		m := msg.(int) // 即使断言失败，本协程的 recover 也能接住
		fmt.Println("msg: ", m)
	}
}

func main() {
	a := make(chan interface{}, 100)
	go safeExec(a)
	a <- "1"
	time.Sleep(time.Second)
	fmt.Println("程序没有崩溃，继续运行")
}

⚠️ 新手必踩的坑： 类型断言 m := msg.(int) 这种不带逗号 ok 的写法，一旦实际类型不符就直接 panic。从 channel 里取出 interface{} 后断言，永远用 m, ok := msg.(int) 的逗号 ok 形式，否则一个脏数据就能炸掉整个程序。另外，recover 永远要和"可能 panic 的代码"待在同一个 goroutine，并且那个 goroutine 的函数要能正常返回（别写在永不退出的 for{} 里）。

考点总结：

• recover 只在当前 goroutine 的调用栈上有效，跨 goroutine 的 panic 捕获不到 → 每个会 panic 的 goroutine 入口都要自己注册 defer recover。
• defer 只在所在函数返回时执行；写在永不返回的 for{} 循环里的 defer 永远不会触发。
• 不带逗号 ok 的类型断言 x.(T) 在类型不符时直接 panic，处理 interface{} 务必用 x, ok := v.(T)。

十一、defer 参数的"立即求值"延伸到嵌套调用

对应《Go 进阶实战 100 题》问题 23。这是 defer 参数求值最经典的面试题：defer calc("1", a, calc("10", a, b)) 里那个嵌套的 calc("10", a, b) 会在注册时立刻执行。

11.1 用生活类比先建立直觉

前面讲过 defer 直接传参像"拍照定格”——参数在按快门那一刻就定格了。这里要补一句：按快门时，连括号里那个嵌套的函数调用也一起立刻按了快门（立刻执行并打印），定格下来的结果才拿去当外层调用的参数。等到真正执行 defer 时，用的全是当时定格好的值，和现在变量变成什么样无关。

graph TD
    subgraph 注册阶段-立即求值
        R1[执行 defer calc("1", a, calc("10", a, b))]
        R1 --> R2[嵌套 calc("10", 1, 2) 立刻执行
打印 10 1 2 3]
        R2 --> R3[a = 0]
        R3 --> R4[执行 defer calc("2", a, calc("20", a, b))]
        R4 --> R5[嵌套 calc("20", 0, 2) 立刻执行
打印 20 0 2 2]
        R5 --> R6[b = 1]
    end
    subgraph 执行阶段-LIFO
        E1[main 返回前]
        E1 --> E2[后注册先执行 calc("2", 0, 2)
打印 2 0 2 2]
        E2 --> E3[先注册后执行 calc("1", 1, 3)
打印 1 1 3 4]
    end

桥接： “按快门时把嵌套调用也一起执行"对应 defer 语句在执行到的那一刻，就已经把所有实参（含嵌套的普通函数调用）求值完毕。所以 calc("10", a, b) 不是等到 defer 执行时才跑，而是注册时就跑完了、还顺手把返回值定格成外层 calc 的 b 参数。

11.2 工程要点

知识点：defer 的实参（含嵌套调用）在注册时全部求值

package main

import "fmt"

func calc(index string, a, b int) int {
	ret := a + b
	fmt.Println(index, a, b, ret)
	return ret
}

func main() {
	a := 1
	b := 2

	// 步骤1：注册第一个 defer。注意：这一刻所有实参都被求值！
	//   其中嵌套的 calc("10", a, b) 会【立即执行】
	//   此时 a=1, b=2，打印 "10 1 2 3"，返回值 3 被定格为外层 calc 的 b 参数
	defer calc("1", a, calc("10", a, b))

	a = 0

	// 步骤2：注册第二个 defer。嵌套的 calc("20", a, b) 立即执行
	//   此时 a=0, b=2，打印 "20 0 2 2"，返回值 2 被定格
	defer calc("2", a, calc("20", a, b))

	b = 1

	// 主函数返回前，两个 defer 按 LIFO 执行：
	//   后注册的 calc("2", 0, 2) 先执行 —— 打印 "2 0 2 2"
	//   先注册的 calc("1", 1, 3) 后执行 —— 打印 "1 1 3 4"
}

输出（注意顺序，前两条是注册阶段打印的，后两条是返回阶段打印的）：

10 1 2 3
20 0 2 2
2 0 2 2
1 1 3 4

⚠️ 新手必踩的坑： 很多人以为 defer calc("1", a, calc("10", a, b)) 里的 calc("10", a, b) 会"延迟"到 defer 执行时才跑。错！凡是写在 defer 语句实参位置的表达式（包括嵌套的普通函数调用），都在 defer 注册那一刻求值完毕。所以这道题会先看到 10 ... 和 20 ... 两条立即输出的日志，而真正的 defer 执行反而排在后面。想让某段逻辑延迟执行，必须把它放进 defer 后面的函数体里（用闭包），而不是放在实参位置。

考点总结：

• defer 的实参在注册时求值并定格，不是函数返回时；这同样适用于实参位置上的嵌套函数调用——它会被立即执行。
• 因此 defer calc("1", a, calc("10", a, b)) 中的 calc("10", a, b) 在注册时就已经跑完、打印并产出了返回值。
• 变量在 defer 注册之后被修改，不影响已经被定格的外层实参；但嵌套调用用的是它执行那一刻的变量值。
• defer 整体仍遵循 LIFO 执行顺序。

十二、自测题与动手练习

自测题

1. 以下代码输出什么？解释原因。

func test() {
    for i := 0; i < 3; i++ {
        defer fmt.Println(i)
    }
}

2. 以下代码输出什么？

func test() {
    for i := 0; i < 3; i++ {
        defer func() {
            fmt.Println(i)
        }()
    }
}

3. 以下两个函数分别返回什么？

func f1() (r int) {
    defer func() { r = 100 }()
    return 1
}

func f2() int {
    r := 1
    defer func() { r = 100 }()
    return r
}

4. 以下代码会发生什么？

func main() {
    go func() {
        panic("子goroutine崩溃")
    }()
    time.Sleep(time.Second)
}

5. goroutine 的初始栈大小是多少？最大可以增长到多少？

动手练习

练习 1： 写一个函数 withRecover(fn func() error) error，它调用 fn，如果 fn panic 则捕获并返回一个包含 panic 信息的 error，否则正常返回 fn 的结果。

练习 2： 写一个程序，启动 3 个 goroutine 并发往 channel 发送数据，用 select + 随机性证明哪个先到就处理哪个。再尝试将其中一个 channel 设为 nil，观察 select 行为变化。

练习 3： 写一个递归函数模拟"深度调用”，在递归前后用 runtime.Stack 打印调用栈信息，观察栈深度变化。尝试把递归深度设为 100 万，观察是否触发栈溢出。

十三、本章小结

本章围绕 Go 的 defer、panic、recover 与函数调用栈展开，核心要点如下：

• defer 的 LIFO 执行：defer 在注册时把任务压入栈，函数返回前按后进先出顺序执行。这保证了"后注册的先执行”，适合资源释放场景。
• 参数立即求值 vs 闭包延迟求值：直接传参在注册时定格值（拍照），闭包在执行时读取引用（录像）。循环中使用 defer 时要特别注意这个区别。
• defer 修改返回值：命名返回值是函数作用域内的真实变量，defer 可以修改；匿名返回值在赋值后 defer 无法触及。
• panic 与 recover：panic 沿调用栈向上传播，每层 defer 都会执行；recover 必须在 defer 中调用才能生效；跨 goroutine 的 panic 无法被捕获，每个 goroutine 都应注册 recover。
• 函数调用栈：每次函数调用创建一个栈帧，包含返回地址、BP、参数、局部变量和返回值空间。函数返回后栈帧销毁，局部变量失效。
• goroutine 栈：初始 2 KB，可动态扩容到 1 GB，采用拷贝式扩容并更新所有指针。相比系统线程的固定 MB 级栈，goroutine 栈更轻量。
• select 底层：随机选择就绪 case、nil channel 永不就绪、lockorder 防死锁、无 default 则阻塞。
• 栈帧里的寄存器与 defer 链表：栈帧除参数/局部变量/返回值外，还有返回地址与 BP 旧值；SP/BP/PC 是 CPU 寄存器。defer 通过 g._defer 头插法链表记录任务，这正是 LIFO 的底层来源。
• WaitGroup：Add 原子增减 counter、Done 等价于 Add(-1)、Wait 在计数 > 0 时经信号量 sema 挂起，归零时 semrelease 唤醒；不能复制、Add 必须在启动协程前完成。

掌握这些机制后，你不仅能写出更健壮的 Go 代码，还能在面试中准确回答关于 defer 执行顺序、参数求值时机、panic 传播路径、栈帧布局与 WaitGroup 底层等高频问题。下一章我们将深入 channel 的底层实现与并发同步原语。

for _, v := range values {
  defer fmt.Println(v) // 输出的是最后一个 v！
}

for _, v := range values {
  v := v // 创建本地副本
  defer func() { fmt.Println(v) }()
}

for i := range values {
  defer func(i int) { fmt.Println(values[i]) }(i)
}