Go 学习笔记：defer 延迟执行 & panic/recover 异常处理

Go 学习笔记：defer 延迟执行 & panic/recover 异常处理

一、defer —— 延迟执行的艺术

1.1 什么是 defer？

defer 是 Go 语言中一个独特的关键字。它的作用非常直观：在函数返回之前，执行一段指定的清理逻辑。

你可以把 defer 理解为一个"临终嘱托"——在函数生命周期的最后一刻，不管它是正常死亡（return）还是意外死亡（panic），这些托管的任务都会被执行。

func readSomething(filename string) error {
    f, err := os.Open(filename)
    if err != nil {
        return err
    }
    defer f.Close() // 无论函数如何退出，文件都会被关闭

    // ... 处理文件内容 ...
    return nil
}

上面的代码中，defer f.Close() 这一行的意思是：“先记下来，等这个函数结束的时候，帮我调用 f.Close()”。于是无论后面的逻辑多复杂、有多少个 return，文件的关闭操作都会被稳妥地执行。

1.2 为什么需要 defer？

在没有 defer 之前，我们是这样管理资源的：

func badOldWay() error {
    f, err := os.Open("data.txt")
    if err != nil {
        return err
    }

    data := make([]byte, 100)
    _, err = f.Read(data)
    if err != nil {
        f.Close() // 手动关闭，容易遗漏
        return err
    }

    err = process(data)
    if err != nil {
        f.Close() // 又一个手动关闭
        return err
    }

    f.Close() // 第三个手动关闭
    return nil
}

问题显而易见：

• 每次 return 前都要记得 f.Close()，只要漏了一个就资源泄漏
• 随着函数变复杂，维护成本指数级增长
• 阅读代码时，资源释放逻辑散落在各处

defer 把"获取资源"和"释放资源"放在一起，极大地提升了可读性和安全性。

1.3 三条核心规则

规则一：LIFO 执行顺序（后进先出）

多个 defer 语句像叠盘子一样——后放的先执行。Go 内部用栈结构来管理它们。

func stackOrder() {
    defer fmt.Println("第一个 defer")
    defer fmt.Println("第二个 defer")
    defer fmt.Println("第三个 defer")
    fmt.Println("函数主体")
}

// 输出：
// 函数主体
// 第三个 defer
// 第二个 defer
// 第一个 defer

这个特性在管理多层嵌套资源时特别有用。比如你同时打开了一个数据库连接、开启了一个事务、获取了一把锁——按照"先获取后释放"的原则，它们的 defer 顺序正好是逆序执行：

func criticalWork() {
    mu.Lock()
    defer mu.Unlock() // 最后释放：外层锁

    tx, _ := db.Begin()
    defer tx.Rollback() // 中间释放：事务

    f, _ := os.Create("output.txt")
    defer f.Close() // 最先释放：文件

    // ... 核心逻辑 ...
    tx.Commit() // 如果提交成功，Rollback 就变成空操作
}

执行顺序：f.Close() → tx.Rollback() → mu.Unlock()

规则二：参数在声明时求值，而非执行时

这是初学者最容易掉进去的坑。defer 后面跟的函数调用，它的参数在 defer 语句执行的那一刻就被确定了，而不是在延迟函数真正运行时才去取值。

func paramTrap() {
    count := 10

    defer fmt.Println("直接传参:", count) // 参数在此时求值: count = 10

    count = 200
    fmt.Println("修改后的值:", count)
    // 函数结束时，defer 打印的是 10，不是 200
}

// 输出：
// 修改后的值: 200
// 直接传参: 10

为什么会这样？可以把 defer 想象成在执行的那一瞬间拍了一张快照——它把当前参数的值"冻结"下来，存到自己的参数槽里。后面的 count = 200 已经影响不到那张快照了。

那如果我真的想在 defer 里拿到最新值怎么办？ 用闭包：

func closureFix() {
    count := 10

    defer func() {
        fmt.Println("闭包捕获:", count) // 执行时才读取 count
    }()

    count = 200
    fmt.Println("修改后的值:", count)
}

// 输出：
// 修改后的值: 200
// 闭包捕获: 200

闭包中引用的外部变量是"活"的——延迟函数执行时才去读取当前值。

补充注意： 如果参数是指针解引用（如 s[0]），情况另有不同：s[0] 是指针解引用表达式，它返回的是底层数组的指针指向的值，不是变量本身，所以 defer 执行时读取的是最终值。这个问题比较微妙，但在生产实践中最常见的坑还是"直接传参"和"闭包"的区别。

规则三：defer 可以修改命名返回值

Go 中 return 语句并不是一个原子操作。它在底层分为三步：

1. 将返回值赋值给返回值变量（若有命名返回值则直接赋值，匿名返回值则赋值给隐式变量）
2. 逆序执行所有 defer
3. 真正从函数返回（RET 指令）

这意味着：如果函数有命名返回值，defer 中的闭包可以在第二步修改它，从而影响最终的返回结果。

func counting() (result int) {
    defer func() {
        result++ // 在 return 之后、真正返回之前执行
    }()
    return 5
}

fmt.Println(counting()) // 输出: 6

执行过程：

1. return 5 → result = 5
2. defer 闭包执行 → result++，变成 6
3. 函数返回 6

这个特性在实际中常用来：

• 包装错误信息：在 defer 中给 error 附加上下文
• 记录返回值：在 defer 中打印函数的输入输出用于调试
• 统一后处理：无论函数从哪个 return 退出，都能在 defer 中对结果做统一处理

比如一个实用的错误包装模式：

func processFile(path string) (err error) {
    f, openErr := os.Open(path)
    if openErr != nil {
        return openErr
    }
    defer f.Close()

    // 用 defer 统一包装错误，附加文件名信息
    defer func() {
        if err != nil {
            err = fmt.Errorf("处理文件 %s 失败: %w", path, err)
        }
    }()

    // ... 处理逻辑 ...
    return nil
}

1.4 循环中的 defer 陷阱

这是一个隐蔽但危险的问题。在 for 循环中使用 defer 时，延迟函数会在整个外层函数结束时才执行，而不是每次循环迭代结束。

// 危险写法：可能导致文件描述符耗尽
func processMany(files []string) error {
    for _, name := range files {
        f, err := os.Open(name)
        if err != nil {
            return err
        }
        defer f.Close() // 危险！这些文件要等到函数结束时才关闭

        // ... 处理 f ...
    }
    return nil
}

如果 files 有 1000 个文件，那么 1000 个句柄会一直打开，直到函数返回才一次性关闭。极端情况下会耗尽系统的文件描述符限制。

正确的做法是把循环体抽成一个独立函数：

func processMany(files []string) error {
    for _, name := range files {
        if err := processOne(name); err != nil {
            return err
        }
    }
    return nil
}

func processOne(name string) error {
    f, err := os.Open(name)
    if err != nil {
        return err
    }
    defer f.Close() // 每次 processOne 返回时立即关闭

    // ... 处理 f ...
    return nil
}

processOne 每次调用结束后，它的 defer 就会执行，文件及时释放。这是 Go 社区广泛推荐的处理模式。

1.5 defer 的典型应用场景

二、panic 和 recover —— 紧急情况的处理

2.1 什么是 panic？

panic 是 Go 语言中的紧急中止机制。当程序遇到无法继续执行的情况时——比如数组越界、空指针解引用，或者你主动调用 panic()——Go 运行时就会触发 panic。

panic 发生后的事情：

1. 当前函数立即停止执行
2. 从当前函数开始，逆序执行所有已注册的 defer
3. 沿着调用栈向上传播，每经过一层就执行该层的 defer
4. 最终程序崩溃，打印 panic 信息和完整调用栈

func demo() {
    fmt.Println("程序开始")
    panic("出大事了！")
    fmt.Println("这行永远不会执行")
}

2.2 什么时候应该主动调用 panic？

总的原则是：能通过 error 处理的就不要用 panic。

以下情况可以考虑 panic：

• 程序初始化阶段的致命错误：配置文件缺失、必需的数据库连不上、端口被占用等——程序没法跑下去
• 内部逻辑不一致：理论上不可能到达的代码分支，比如 switch 的 default 分支处理了一个不应该存在的枚举值
• “Must” 系列函数：提供给调用者的便捷版本，当调用者能保证输入合法时使用

// 标准库中的典范 —— template.Must 和 regexp.MustCompile
func MustCompile(str string) *Regexp {
    regexp, err := Compile(str)
    if err != nil {
        panic(`regexp: Compile(` + quote(str) + `): ` + err.Error())
    }
    return regexp
}

// 用法：包级别变量初始化，编译时正则不可能出错
var phonePattern = regexp.MustCompile(`^1[3-9]\d{9}$`)

命名约定：这类函数通常以 Must 开头，示意调用者"请确保你的输入正确，否则我就 panic"。

2.3 recover —— 在悬崖边抓住你

recover 是 Go 语言的内置函数，它只能在 defer 函数内部生效。当 panic 发生时，recover 可以捕获 panic 的值，让程序从崩溃中恢复过来。

关键点：

• recover 只能在 defer 函数中直接或间接调用才有效
• 如果没发生 panic，recover 返回 nil
• recover 不能跨 goroutine 工作

func safeCall() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("捕获到 panic:", r)
        }
    }()

    doSomethingDangerous()
    fmt.Println("这行不会执行") // panic 后面的代码被跳过
}

func doSomethingDangerous() {
    panic("Boom!")
}

重要认知：recover 不是 try-catch！在 Java/C# 中，catch 块执行完毕后可以继续执行 try 块后面的代码。而 Go 的 recover 只是阻止程序崩溃，panic 发生点之后的代码永远不会被执行。控制权回到 defer 所在函数的调用方。

2.4 panic 与 defer 的协作

panic 发生时，defer 仍然会执行。这是 Go 设计中最精妙的部分之一——即使在最坏的情况下，清理逻辑也不会被跳过。

func panicDemo() {
    defer fmt.Println("defer 1: 关闭数据库连接")
    defer fmt.Println("defer 2: 释放文件锁")
    defer fmt.Println("defer 3: 记录日志")

    panic("内部错误")
}

// 输出：
// defer 3: 记录日志
// defer 2: 释放文件锁
// defer 1: 关闭数据库连接
// panic: 内部错误
// ... 堆栈信息 ...

2.5 精细化 recover：选择性恢复

不加区分地恢复所有 panic 是危险的——你可能掩盖了真正的 bug，还可能导致程序在不一致的状态下继续运行。

Go 社区的共识是：只恢复你预期中的 panic，意外的 panic 应该重新抛出。

// 定义一个专用类型用于"可控 panic"
type sentinelPanic struct {
    message string
}

func processItems(items []string) (result string, err error) {
    defer func() {
        switch v := recover(); v {
        case nil:
            // 正常情况，无需处理
        case sentinelPanic{}:
            // 这是我们自己触发的可控 panic，转换为 error 返回
            err = fmt.Errorf("处理中断: %v", v)
        default:
            // 未知的 panic，不能吞掉，重新抛出
            panic(v)
        }
    }()

    for _, item := range items {
        if item == "" {
            panic(sentinelPanic{message: "发现空元素"})
        }
        result += item + ","
    }
    return result, nil
}

这种模式的关键在于：

1. 用特定类型标记"可预期"的 panic
2. recover 时做类型检查
3. 未知类型原样 panic(v) 重新抛出，保持栈信息不丢失

2.6 Go 错误处理哲学

Go 和 Java/Python 的错误处理理念根本不同：

Go 的设计者认为：程序中绝大多数"错误"是可预期的，应该作为正常控制流的一部分来显式处理。panic 只保留给真正的"意外"。

实践指南：

• ✅ 优先使用 error 返回值处理预期错误
• ✅ 在库代码中永远不要 panic，除非函数名以 Must 开头
• ✅ 在 goroutine 的顶层加 defer recover 防止一个 goroutine 崩溃拖垮整个程序
• ❌ 不要用 panic/recover 替代正常的错误处理
• ❌ 不要不加区分地 recover 所有 panic
• ❌ 不要跨 goroutine 依赖 recover（每个 goroutine 有自己独立的 panic 栈）

三、练习代码

练习 1：defer 执行顺序观察

package main

import "fmt"

// 观察多个 defer 的执行顺序
func deferStack() {
    fmt.Println("=== defer 栈式执行 ===")

    for i := 1; i <= 5; i++ {
        defer fmt.Printf("defer #%d 执行\n", i)
    }

    fmt.Println("函数主体执行完毕")
}

// 输出：
// === defer 栈式执行 ===
// 函数主体执行完毕
// defer #5 执行
// defer #4 执行
// defer #3 执行
// defer #2 执行
// defer #1 执行

练习 2：defer 参数求值的时机

package main

import "fmt"

// 对比直接传参和闭包两种方式的差异
func paramVsClosure() {
    fmt.Println("=== 参数求值时机对比 ===")

    x := 1

    // 方式一：直接传参 —— 参数在 defer 注册时就被冻结
    defer fmt.Printf("直接传参方式: x = %d\n", x)

    // 方式二：闭包捕获 —— 执行时才读取最新值
    defer func() {
        fmt.Printf("闭包捕获方式: x = %d\n", x)
    }()

    x = 100
    fmt.Printf("函数执行中: x = %d\n", x)
}

// 输出：
// === 参数求值时机对比 ===
// 函数执行中: x = 100
// 闭包捕获方式: x = 100
// 直接传参方式: x = 1

练习 3：defer 修改返回值

package main

import (
    "errors"
    "fmt"
)

// 演示 defer 如何影响命名返回值
func modifyReturn() (result int) {
    defer func() {
        result *= 2 // 在 return 之后修改返回值
    }()
    return 10
}

// 实际应用：在 defer 中包装错误信息
func readConfig(path string) (config string, err error) {
    // 无论如何都会附加文件路径到错误信息中
    defer func() {
        if err != nil {
            err = fmt.Errorf("读取配置 %s 出错: %w", path, err)
        }
    }()

    // 模拟一个会失败的读取操作
    return "", errors.New("文件格式错误")
}

func main() {
    fmt.Println("modifyReturn:", modifyReturn()) // 输出 20

    _, err := readConfig("/etc/app.conf")
    fmt.Println("包装后的错误:", err)
    // 输出: 读取配置 /etc/app.conf 出错: 文件格式错误
}

练习 4：recover 捕获 panic

package main

import "fmt"

// 安全的除法函数 —— 除零时不会崩溃
func safeDivide(a, b int) (result int, err error) {
    defer func() {
        if r := recover(); r != nil {
           	err = fmt.Errorf("除法运算 panic: %v", r)
            result = 0
        }
    }()

    result = a / b // 如果 b == 0，这里会 panic
    return result, nil
}

func main() {
    // 正常情况
    if v, err := safeDivide(10, 2); err != nil {
        fmt.Println("错误:", err)
    } else {
        fmt.Println("10 / 2 =", v)
    }

    // 除零情况 —— 被 recover 安全捕获
    if v, err := safeDivide(10, 0); err != nil {
        fmt.Println("错误:", err)
    } else {
        fmt.Println("10 / 0 =", v)
    }
}

// 输出：
// 10 / 2 = 5
// 错误: 除法运算 panic: runtime error: integer divide by zero

练习 5：资源管理综合练习

package main

import (
    "fmt"
    "os"
)

// 模拟一个数据处理管道：
// 打开源文件 → 读取 → 写入目标文件 → 两边的文件都需要妥善关闭
func copyFile(src, dst string) (err error) {
    // 打开源文件
    sf, err := os.Open(src)
    if err != nil {
        return fmt.Errorf("无法打开源文件: %w", err)
    }
    defer sf.Close() // 保证源文件关闭

    // 创建目标文件
    df, err := os.Create(dst)
    if err != nil {
        return fmt.Errorf("无法创建目标文件: %w", err)
    }
    defer df.Close() // 保证目标文件关闭（但这里有个坑，见注释）

    // 读取并写入数据
    buf := make([]byte, 1024)
    n, err := sf.Read(buf)
    if err != nil {
        return fmt.Errorf("读取源文件失败: %w", err)
    }

    _, err = df.Write(buf[:n])
    if err != nil {
        return fmt.Errorf("写入目标文件失败: %w", err)
    }

    return nil
}

// 注释：上面的 df.Close() 有个微妙之处——文件关闭本身也可能产生错误（尤其是在 NFS 等
// 网络文件系统上，写入错误可能被延迟到 close 时才报告）。
// 在生产代码中，通常需要显式处理 close 的错误而不是 defer：
//
//   defer func() {
//       if closeErr := df.Close(); closeErr != nil && err == nil {
//           err = closeErr
//       }
//   }()
//
// 这个细节说明了 defer 虽好，但也要理解具体场景的需求。

func main() {
    err := copyFile("/tmp/source.txt", "/tmp/dest.txt")
    if err != nil {
        fmt.Println("复制失败:", err)
    } else {
        fmt.Println("文件复制成功！")
    }
}

练习 6：HTTP 服务中的 panic 中间件

package main

import (
    "fmt"
    "log"
    "net/http"
    "runtime/debug"
)

// 中间件：捕获 handler 中的 panic，防止整个服务崩溃
func recoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                // 记录完整的堆栈信息，方便排查问题
                log.Printf("PANIC [%s %s]: %v\n%s",
                    r.Method, r.URL.Path, rec, debug.Stack())

                // 给客户端返回 500
                http.Error(w,
                    "内部服务错误，请稍后重试",
                    http.StatusInternalServerError)
            }
        }()

        next.ServeHTTP(w, r)
    })
}

// 一个可能 panic 的 handler
func riskyHandler(w http.ResponseWriter, r *http.Request) {
    // 模拟某些不可预期的情况
    numbers := []int{1, 2, 3}
    // 故意越界访问，触发 panic
    _ = numbers[10]

    fmt.Fprintln(w, "Hello, World!")
}

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", riskyHandler)

    // 用中间件包装
    server := recoveryMiddleware(mux)

    log.Println("服务启动在 :8080")
    http.ListenAndServe(":8080", server)
}

四、今日总结

下一课计划: 2.4 函数收尾 —— 可变参数（variadic），以及进入 2.5 方法与接口的学习