Go语言recover在微服务接口中的实践方法-Golang-PHP中文网

recover不能替代error，仅用于http/rpc入口等“最后一道防线”防止单个请求崩溃服务；它不修复错误、不回滚副作用、不恢复执行流，滥用会掩盖错误、破坏错误可追溯性。

go语言recover在微服务接口中的实践方法

recover 不能替代 error 处理，它只该用在 HTTP handler 或 RPC 入口这类“最后一道防线”上，防止单个请求 panic 导致整个服务崩溃。

为什么不能在业务函数里随便加 recover

recover 的作用不是“修复错误”，而是“阻止崩溃”。它无法回滚已发生的副作用（比如已写入的数据库记录、已发的 HTTP 请求、已 close 的 channel），也不能恢复 panic 后的执行流。
常见错误是把 recover 塞进某个工具函数里，结果：

掩盖了本该由调用方处理的 error，比如 json.Unmarshal 失败本该返回 err，却用 panic + recover 吞掉
让 panic 变成静默失败，日志里只看到 nil，排查时完全找不到源头
破坏调用链的错误可追溯性——上层无法用 errors.Is 或 errors.As 判断错误类型

HTTP handler 中正确使用 defer-recover 的模式

真正该加 recover 的地方，是每个独立的请求入口。它要做的事很明确：记录 panic、返回 500、不中断服务器进程。
典型结构如下：

func handleUserRequest(w http.ResponseWriter, r *http.Request) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("PANIC in %s %s: %v", r.Method, r.URL.Path, r)
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        }
    }()

    // 正常业务逻辑，这里可以放心用各种可能 panic 的操作
    // 比如：解析未校验的 JSON、访问空指针、map 并发读写等
    user, err := parseUserFromRequest(r)
    if err != nil {
        http.Error(w, err.Error(), http.StatusBadRequest)
        return
    }
    // ...
}

必须用匿名函数包裹 recover()，直接写 defer recover() 无效
日志里要包含请求路径和方法，否则线上出问题根本定位不到哪个接口崩了
不要在 recover 里尝试重试或降级——那是 error 的事；recover 只负责兜底

context.WithTimeout 和 recover 配合的关键点

超时和 panic 是两类不同问题，但容易混淆：
context.DeadlineExceeded 是正常 error，应走 if err != nil 分支；而 panic 是运行时崩溃，必须靠 recover 拦截。
错误做法是把超时也塞进 recover：

// ❌ 错误：把超时当 panic 处理
if ctx.Err() == context.DeadlineExceeded {
    panic("timeout") // 不该 panic，应该 return err
}

超时、取消、连接拒绝这些都属于可预期错误，必须用 error 返回并由上层判断
如果下游服务超时后还继续操作（比如往已关闭的 channel 发数据），那才可能触发 panic，这时 recover 才起作用
真正需要 recover 的 panic 场景：切片越界、nil 指针解引用、map 并发写、类型断言失败等运行时错误

微服务中 recover 容易被忽略的边界

goroutine 隔离是关键。一个 HTTP handler 启动的 goroutine 里发生的 panic，主 handler 的 defer 是捕获不到的。
例如：

go func() {
    // 这里的 panic 不会被 handleUserRequest 的 defer 捕获
    riskyOperation()
}()

每个独立 goroutine 都要自己配 defer-recover，或者统一用 go-worker 类库封装
RPC 客户端调用（如 gRPC）的 stream.Recv 等阻塞方法，如果没加超时且服务端挂了，可能卡死而不是 panic——这不属于 recover 覆盖范围
recover 对 os.Exit、syscall.Kill 等进程级终止完全无效

最常被漏掉的是中间件链中的 panic：如果用了自定义中间件，且中间件本身没包 defer-recover，那它内部 panic 就会穿透到 handler 层——此时 handler 的 recover 才是最后一道保险，但日志上下文已经丢失。