深入理解 Go 的 panic/recover：为什么 recover 只能捕获当前 goroutine 的 panic？

在 Go 语言中，panic 和 recover 是一对用于处理程序异常的内置函数。它们提供了类似其他语言中 try-catch 的能力，但设计哲学截然不同。一个关键的限制是：recover 只能捕获当前 goroutine 中发生的 panic。如果 panic 发生在另一个 goroutine 中，即便你在外层 goroutine 使用了 recover，程序依然会崩溃。本篇教程将从基础用法出发，通过原理剖析和代码实战，彻底讲透这一重要特性。

panic 和 recover 的基础用法

在深入 goroutine 相关行为之前，我们先回顾一下 panic 和 recover 的基本操作。

什么是 panic？

panic 内置函数会立刻停止当前函数的正常执行，并开始沿调用栈向上“冒泡”，逐层执行每层函数中已注册的 defer 语句。如果这一路都没有遇到 recover，程序最终会退出，并打印出完整的堆栈信息。

func doSomething() {
    panic("something went terribly wrong")
}

什么是 recover？

recover 内置函数用于重新获得 panic 协程的控制权。它只能在 defer 函数内部直接调用时才有效。当 recover 在 defer 函数里被调用，且该 goroutine 正处于 panic 传播过程中时，recover 会捕获 panic 传递的值，并恢复正常执行。

func safeCall() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from:", r)
        }
    }()
    // 可能触发 panic 的代码
    doSomething()
    fmt.Println("This line will not be printed if panic occurs")
}

上面这段代码中，doSomething() 触发的 panic 会被同 goroutine 内的 defer 中的 recover 捕获，程序不会崩溃。

困境：跨 goroutine 的 panic 无法被捕获

很多初学者会误以为在主 goroutine 中使用 recover 可以捕获子 goroutine 抛出的 panic。让我们看一个反例：

package main

import (
    "fmt"
    "time"
)

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Main goroutine recovered:", r)
        }
    }()

    go func() {
        panic("panic in child goroutine")
    }()

    // 等待一会儿，确保子 goroutine 执行
    time.Sleep(time.Second)
    fmt.Println("This line will never be printed")
}

运行后你会发现：程序直接崩溃，打印出子 goroutine 的 panic 信息，主 goroutine 中的 recover 完全没有生效。输出类似：

panic: panic in child goroutine

goroutine 6 [running]:
...

这是因为 recover 存在严格的 goroutine 作用域限制。

原理：为什么 recover 只能捕获本 goroutine 的 panic？

要理解这个限制，需要明白 Go 运行时是如何处理 panic 和 goroutine 的。

每个 goroutine 拥有独立的调用栈

Goroutine 是 Go 中的轻量级线程，每个 goroutine 都拥有自己独立的、动态增长的栈空间。正常的函数调用、defer 链表、以及 panic 状态 都存储在与该 goroutine 关联的数据结构中。

当一个 panic 被触发时，它只会在当前 goroutine 的栈上向上传播。传播路径上的 defer 函数会被执行，如果其中调用了 recover，则该 goroutine 的 panic 被终止。如果没有 recover，当前 goroutine 退出并打印堆栈，最终可能导致整个进程崩溃（如果这是最后活跃的 goroutine）。

recover 查找的是当前 goroutine 的 panic 状态

recover 的实现逻辑大致是：检查当前 goroutine 的执行上下文中是否有一个正在传播的 panic。如果有，返回该 panic 的值并停止传播；如果没有，返回 nil。它绝不会去查看其他 goroutine 的状态，因为 goroutine 之间不共享栈，也没有共享的 panic 链表。这种设计保证了隔离性和简洁性。

可以把这个模型类比为：每个 goroutine 都是一条独立的“执行轨迹”，panic 就像在这条轨迹上燃起的大火，而 recover 是安装在同一条轨迹上的灭火器。别的轨迹上的灭火器无法扑灭你这条轨迹上的火。

实战：演示并验证跨 goroutine 行为

下面通过几个精心设计的实验，帮助你直观理解这一机制。

实验一：子 goroutine 内自己 recover（正确）

在产生 panic 的同一个 goroutine 中放置 recover，可以正常工作。

func main() {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                fmt.Println("Child goroutine recovered:", r)
            }
        }()
        panic("oops!")
    }()

    time.Sleep(time.Second)
    fmt.Println("Main continues normally")
}

输出：

Child goroutine recovered: oops!
Main continues normally

实验二：从外部 goroutine 尝试 recover（失败）

这正是文章开头展示的例子，主 goroutine 中的 recover 完全无效，程序崩溃。

实验三：多个子 goroutine 各自 panic

每个 goroutine 都必须自己处理自己的 panic。

func worker(id int) {
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("Worker %d recovered: %v\n", id, r)
        }
    }()
    if id%2 == 0 {
        panic(fmt.Sprintf("even worker %d panicked", id))
    }
    fmt.Printf("Worker %d finished successfully\n", id)
}

func main() {
    for i := 0; i < 4; i++ {
        go worker(i)
    }
    time.Sleep(time.Second)
}

输出（顺序可能不同）：

Worker 2 recovered: even worker 2 panicked
Worker 3 finished successfully
Worker 1 finished successfully
Worker 0 recovered: even worker 0 panicked

通过对比，recover 的作用范围仅限于触发它的那个 goroutine，这一事实变得非常清晰。

最佳实践与注意事项

理解这一机制后，在编写并发 Go 代码时，需要遵循一些重要的实践准则。

1. 在每一个可能 panic 的 goroutine 入口处做好 recover

不要依赖外层的 recover，要为每个子 goroutine 的顶层函数添加 defer/recover 保护。这通常被称为“边界防护”模式。

func safeGo(fn func()) {
    go func() {
        defer func() {
            if r := recover(); r != nil {
                log.Printf("goroutine panic recovered: %v", r)
            }
        }()
        fn()
    }()
}

凡是使用 go 关键字启动的函数，都应该确保它自身具备恢复能力，避免整个程序悄然退出。

2. 使用同步原语传递错误

如果子 goroutine 需要通过 recover 捕获 panic 并将其作为错误传递给父 goroutine，可以利用 channel 或者 sync.WaitGroup + 共享变量来实现，但要注意数据竞争。

更推荐使用 golang.org/x/sync/errgroup 包，它可以方便地管理一组 goroutine，并收集第一个发生的错误（包括 panic 转换为 error）。

import "golang.org/x/sync/errgroup"

func main() {
    g := new(errgroup.Group)
    g.Go(func() error {
        // 可能 panic 的代码
        return nil
    })
    if err := g.Wait(); err != nil {
        log.Fatal(err)
    }
}