Go recover 为什么只能拦截当前 Goroutine 的 panic 而无法跨协程

理解 panic 与 recover 的本质

思考一个场景：你和同事各自负责独立的项目模块，你在工作中遇到了一个无法解决的致命错误（panic）。你需要的是在自己负责的范围内尝试修复或妥善处理这个错误（recover），而不是期望你同事的模块能突然感知并接手你的问题。

在 Go 语言中，每个 goroutine（协程）就像一个独立的、轻量级的“工作人员”。panic 和 recover 这对机制，本质上是设计给单个 goroutine 使用的错误恢复工具，它的作用域被严格限定在“产生 panic 的那个 goroutine”内部。

剖析工作机制：为什么是“当前”

Go 的运行时（runtime）为每个 goroutine 维护一个独立的执行栈和相关的元数据。panic 和 recover 的行为与这个栈的展开过程紧密绑定。

1. panic 的触发与栈展开：当代码调用 panic() 时，当前 goroutine 的正常执行立即中止。运行时开始展开（unwind） 该 goroutine 的调用栈。这个过程会按顺序执行当前函数中所有已注册的 defer 函数，然后返回到调用该函数的上一层，继续执行那里的 defer，如此反复，直到到达栈顶。

2. recover 的捕捉机制：recover 是一个内建函数，它只能在一个 defer 函数内部直接调用才有效。当栈展开过程执行到某个 defer 函数时，如果这个 defer 函数内部调用了 recover()，并且当时该 goroutine 正处于 panic 导致的栈展开状态，那么：

   • recover 会捕获传给 panic 的值。
   • 停止当前 goroutine 的栈展开过程。
   • recover 返回捕获到的 panic 值。
   • 该 defer 函数正常执行完毕后，控制权将返回到调用 panic 的函数中 panic 语句之后的逻辑（如果有）。

核心要点：recover 的生效条件是“在同一个 goroutine 的栈展开过程中”。它无法感知、更无法干预另一个独立的、拥有自己栈的 goroutine 内部发生的 panic。

验证：代码证明跨协程捕获失败

下面这段代码清晰地展示了 recover 无法跨 goroutine 工作：

package main

import (
    "fmt"
    "time"
)

func mayPanic() {
    panic("a critical error in worker goroutine")
}

func main() {
    // 尝试在主 goroutine 中 recover
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered in main:", r)
        }
    }()

    // 启动一个新的 worker goroutine
    go func() {
        // worker 内部尝试 recover，这是有效的
        defer func() {
            if r := recover(); r != nil {
                fmt.Println("Recovered in worker goroutine:", r)
            }
        }()
        mayPanic()
    }()

    // 主 goroutine 等待一会儿，让 worker 有机会 panic
    time.Sleep(time.Second)
    fmt.Println("Main goroutine continues running.")
}

执行结果与分析：

1. 程序会打印 Recovered in worker goroutine: a critical error in worker goroutine。这表明 recover 在产生 panic 的 worker goroutine 内部成功捕获了错误。
2. 程序会打印 Main goroutine continues running.。主 goroutine 的 defer 中的 recover 什么也没捕获到，因为它捕获的是自己可能发生的 panic，而不是子 goroutine 的。
3. 如果注释掉 worker goroutine 内部的 recover 调用，整个程序将会崩溃并输出 panic: a critical error in worker goroutine。这证明了一个未被捕获的 panic 会导致整个进程退出。

深入设计哲学：隔离与可控

Go 语言做出这种设计，是基于对并发错误处理的深刻思考：

• 故障隔离：一个 goroutine 的崩溃不应该悄无声息地“传染”给其他无关的 goroutine。这保证了系统的健壮性。想象一个 web 服务器，每个请求由独立的 goroutine 处理，一个请求的 panic 不应导致其他正常请求的 goroutine 意外终止。
• 明确的责任：错误应该在产生的地方被处理。强迫 goroutine 自己处理自己的 panic，让错误处理逻辑更清晰、更可预测。跨 goroutine 的错误恢复会使程序行为变得复杂且难以推理。
• 通信优于中断：Go 鼓励使用通道（channel）进行 goroutine 间的通信和协调。当一个 goroutine 出错时，更“Go 风格”的做法是通过 channel 将错误信息发送出去，由一个专门的父级或监控 goroutine 来决策如何处理（比如记录日志、重启 worker、优雅降级）。

正确实践：如何优雅地处理并发 panic

既然不能跨协程 recover，那么当需要管理多个可能 panic 的 goroutine 时，该怎么办？

1. 在每个可能 panic 的 goroutine 内部进行 recover。这是最基础、最正确的方式。

   func safeWorker() {
       defer func() {
           if r := recover(); r != nil {
               // 执行本地清理、记录详细错误日志（包含 goroutine ID、堆栈等）
               log.Printf("Goroutine panic recovered: %v\n", r)
               debug.PrintStack() // 打印堆栈信息，对调试至关重要
           }
       }()
       // ... 可能 panic 的业务逻辑 ...
   }

2. 使用 channel 向外报告错误状态。当 goroutine 内部 recover 后，可以通过 channel 通知外部管理器。

   type WorkerResult struct {
       Output interface{}
       Err    error        // 正常业务错误
       Panic  interface{}  // 被 recover 的 panic 值
   }
   
   func workerWithChannel(out chan<- WorkerResult) {
       defer func() {
           if r := recover(); r != nil {
               out <- WorkerResult{Panic: r}
           }
       }()
       result, err := doWork()
       out <- WorkerResult{Output: result, Err: err}
   }

3. 使用 sync.WaitGroup 等待所有 goroutine 完成并检查错误。结合上面的 channel，可以实现对一组 goroutine 的生命周期和错误状态的管理。

总结：recover 只能拦截当前 goroutine 的 panic，这是由 Go 并发模型和错误恢复机制的底层设计决定的。理解并接受这一点，是编写健壮并发程序的关键。将错误处理的责任明确地放在错误发生的 goroutine 内部，并通过通信机制（如 channel）来协调全局行为，才是符合 Go 语言设计思想的正确做法。