Go语言panic和recover的正确使用姿势

Go语言通过error接口处理常规错误，但在遇到不可恢复的严重错误时，提供了panic机制来中断程序执行。为了避免程序直接崩溃，Go又提供了recover机制用于捕获panic。正确使用这两个机制，是构建健壮Go程序的关键。

1. 理解 panic 的本质

panic类似于Java中的异常或C++中的中断，它会立即停止当前函数的执行，并开始逐层向上运行defer语句，直到程序崩溃或被recover捕获。

运行以下代码，观察程序因数组越界而崩溃的现象：

package main

import "fmt"

func crashDemo() {
    // 定义一个长度为3的数组
    a := [3]int{1, 2, 3}
    // **尝试**访问索引10，这里会触发 panic
    fmt.Println(a[10])
}

func main() {
    crashDemo()
    fmt.Println("这行代码不会被执行")
}

上述代码中，a[10]触发了panic，程序直接终止，main函数中的后续打印语句不会运行。

2. 掌握 recover 的核心规则

recover只有在defer函数中调用时才有效。它的作用类似于“紧急刹车”，能让正在崩溃的程序恢复控制权。

牢记以下核心逻辑：

1. recover只能捕获同一个goroutine内的panic。
2. recover**必须**搭配defer`使用。
3. 如果没有panic发生，recover会返回nil。

3. 正确捕获 panic 的步骤

为了防止程序因意外错误而彻底退出，通常在程序的入口点（如main函数或HTTP请求处理入口）设置恢复机制。

编写一个带有恢复功能的函数模板：

func safeExecute() {
    // **定义**一个匿名函数并延迟执行
    defer func() {
        // **调用** recover() 捕获 panic
        if r := recover(); r != nil {
            // r 即为 panic 传入的参数
            fmt.Println("程序发生 panic，已恢复:", r)
        }
    }()

    // 下面是可能出错的业务逻辑
    fmt.Println("开始执行业务逻辑...")
    panic("遇到致命错误，人工触发的 panic")
    fmt.Println("业务逻辑结束，这里不会执行")
}

func main() {
    safeExecute()
    fmt.Println("程序继续运行，main函数未崩溃")
}

在上述代码中：

1. 声明defer匿名函数确保其在函数退出时执行。
2. 判断recover()返回值是否为nil。
3. 处理异常信息，打印日志并让程序继续向下执行。

4. 执行流程可视化

当程序触发panic时，内部的调用栈展开过程如下。理解这个流程有助于定位recover的最佳放置位置。

从流程图中可以看出，defer是按照“后进先出”的顺序执行的。recover通常放置在最外层（如main或顶层的请求处理器）的defer中，以确保能捕获到内层抛出的任何panic。

5. 谨慎处理 Goroutine 中的 panic

在Go中，开启新的goroutine（使用go关键字）意味着创建了一个独立的调用栈。主goroutine的recover无法捕获子goroutine中的panic。

查看下面的错误示范：

func main() {
    // 主 goroutine 的 recover
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Main 捕获到:", r)
        }
    }()

    // **启动**一个新的 goroutine
    go func() {
        panic("子 goroutine 崩溃了")
    }()

    // 等待一秒让子 goroutine 运行
    // 这里的 time.Sleep 仅作演示，实际生产环境应使用 WaitGroup
    select {}
}

运行上述代码，程序依然会崩溃。因为子goroutine的panic直接传导到了该goroutine的终点，并未被主goroutine拦截。

修正代码，在子goroutine内部加入recover：

func main() {
    go func() {
        // **必须**在子 goroutine 内部单独设置 defer
        defer func() {
            if r := recover(); r != nil {
                fmt.Println("子 goroutine 内部捕获到:", r)
            }
        }()
        panic("子 goroutine 崩溃了")
    }()

    // 防止主程序直接退出
    select {}
}

确保每个可能发生panic的独立goroutine都配置了自己的recover逻辑。

6. 常见场景与最佳实践

为了规范使用，参考下表中的场景建议：

7. 获取崩溃堆栈信息

仅仅捕获panic是不够的，排查问题需要知道具体的堆栈调用。利用debug.PrintStack()可以打印现场信息。

import (
    "fmt"
    "runtime/debug"
)

func detailedRecover() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("捕获到异常:", r)
            // **打印**当前堆栈信息到标准输出
            debug.PrintStack()
        }
    }()

    panic("模拟深层错误")
}

执行上述代码，控制台不仅会输出“捕获到异常”，还会列出具体的文件名和行号，极大缩短了排查时间。

8. 避免滥用 panic

panic仅用于“不可恢复”的错误，如：

• 数组越界
• 空指针引用
• 显式的逻辑死锁

对于可预见的错误（如文件不存在、网络超时），必须使用error返回值处理，而不是panic。

错误示范：

// 文件不存在直接 panic 是不合理的
func readFile() string {
    data, err := os.ReadFile("config.txt")
    if err != nil {
        panic(err) // 错误做法：文件缺失是可预见的
    }
    return string(data)
}

正确做法：

func readFile() (string, error) {
    data, err := os.ReadFile("config.txt")
    if err != nil {
        return "", err // 正确做法：返回 error，由调用者判断
    }
    return string(data), nil
}