Go panic 和 recover 不是异常处理

go func ReadFile(name string) ([]byte, error) { data, err := os.ReadFile(name) if err != nil { return nil, fmt.Errorf("read file: %w", err) } return data, nil }

data, err := ReadFile("config.json") if err != nil { log.Fatalf("failed to read config: %v", err) } // 正常使用 data

这种方式让错误处理变成控制流的一部分，清晰、可读并且强制调用者必须面对错误（或至少显式忽略）。这是 Go 哲学的核心：**错误就是值**，应当被常规地处理和传递。

`panic` 和 `recover` 在这个哲学体系里扮演了一个完全不同、非常特殊的角色。

## 二、panic 的真正语义：不可恢复的程序错误

`panic` 的字面意思是“恐慌”，它的设计意图是 **当程序进入了一个无法继续执行的不可恢复状态时**，立即停止当前 goroutine 的正常执行流程，并沿着调用栈向上传播，直到程序崩溃（除非被 `recover` 捕获）。

典型的 `panic` 场景包括：

- **程序员的逻辑错误**：数组越界、空指针解引用、类型断言失败等运行时错误，本质上是 bug。
- **启动阶段无法满足的依赖**：比如必须连接数据库才能服务，连接失败可以让整个程序 `panic`。
- **显式调用 `panic` 表示“这里不可能发生”**：比如硬编码的 switch 进入 default 分支，但理论上不应该走到那里。

示例：当某个前置条件必须为真，否则程序无法正常工作：

```go
func init() {
    key := os.Getenv("SECRET_KEY")
    if key == "" {
        panic("SECRET_KEY environment variable must be set")
    }
}

重要共识：对于用户输入引起的错误、网络超时、文件不存在等可预期的错误场景，绝对不应该使用 panic。这些都应该通过返回 error 来处理。

三、recover 的定位：防止程序崩溃的最后一道保险

recover 是一个内置函数，只能在 defer 函数中起作用。它用于捕获当前 panic 的值，并将程序控制流恢复到调用 recover 的 defer 函数之后（也就是从发生 panic 的点之后继续执行？不，是让 panic 停止传播，goroutine 恢复正常执行）。

基本形态：

func safeCall() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()
    doSomethingRisky()
}

recover 的正确使用场景

recover 绝对不能作为异常处理来使用。它的合法用例非常有限：

1. 保护基础设施边界（例如 HTTP 服务）

在一个 HTTP 服务器中，某个请求处理函数如果因为空指针等原因发生 panic，不应该让整个服务器进程崩溃。这时可以在请求入口处使用 recover 将 panic 转为 500 错误：

func recoveryMiddleware(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if err := recover(); err != nil {
                log.Printf("panic recovered: %v", err)
                http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            }
        }()
        next.ServeHTTP(w, r)
    })
}

这里并不是在“处理异常”，而是在防止一个未预料的程序错误导致整个系统宕机。

2. 特定库的容错保证

例如 encoding/json 的 Marshal 过程中，如果用户提供的类型实现了 json.Marshaler 并发生了 panic，标准库会 recover 并将 panic 转为错误返回。但这只是保护了调用者的程序不被用户的 bad code 弄崩溃，而不是一种常规错误处理模式。

3. 清理资源或诊断信息

有时在 recover 后可以做一些资源清理、打印堆栈，然后重新引发 panic 或记录日志后退出。这通常用于提供更好的调试信息，而不是让程序继续执行。

4. 在特定 goroutine 中防止程序直接退出

如果一个独立的 goroutine 发生了 panic，且未被 recover，整个进程会崩溃。在关键 goroutine 中使用 recover 可以记录堆栈后安全退出该 goroutine，而不影响主进程。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine panic: %v\nstack: %s", r, debug.Stack())
        }
    }()
    // 可能 panic 的任务
}()

四、错误类比：为什么不是 try-catch

很多从其他语言转过来的开发者会用如下模式，企图模仿异常处理：

// 错误示例：把 panic/recover 当异常传递
func mayPanic() {
    panic("something bad")
}

func call() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    mayPanic()
    return nil
}

这样做有几个严重问题：

1. 滥用语义：正常流程的错误变成了“恐慌”，违背了 Go 错误即值的清晰理念。
2. 性能代价高：panic 和 recover 的实现远比返回 error 开销大，因为它们需要遍历调用栈。
3. 隐藏控制流：调用者以为函数只是普通调用，但内部可能通过 panic 跳跃了多层堆栈，导致可读性极差。
4. 破坏错误处理一致性：团队中部分使用 error 返回，部分用 panic，会让代码维护变成噩梦。

五、最佳实践总结

六、一个实际案例：服务优雅处理 panic

以下是一个典型的 web 服务恢复中间件，展示了 recover 的合理用法：

func RecoveryInterceptor(h http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        defer func() {
            if rec := recover(); rec != nil {
                // 可以记录详细堆栈
                log.Printf("PANIC: %v\n%s", rec, debug.Stack())
                // 返回统一的错误信息，不要泄露内部细节
                http.Error(w, "internal error", http.StatusInternalServerError)
            }
        }()
        h.ServeHTTP(w, r)
    })
}