Golang recover 能捕获所有错误吗?
recover只能捕获由panic引发的运行时错误且必须在defer中调用,无法处理普通error或跨协程panic。
recover 只能捕获由 panic 引发的运行时错误且必须在 defer 中调用,无法处理普通 error 或跨协程 panic。

recover 不能捕获所有错误。它只能捕获由 panic 引发的运行时恐慌,且必须在 defer 中调用才有效。
recover 的作用范围有限
recover 是 Go 语言中用于从 panic 中恢复程序正常执行的内建函数。它只能拦截显式的 panic 调用或某些严重的运行时错误(如数组越界、空指针解引用等),但无法处理普通的错误(error 类型)。
例如,以下情况 recover 无效:
- 函数返回 error,比如文件打开失败、JSON 解码错误
- 未触发 panic 的逻辑错误
必须配合 defer 使用
recover 只有在 defer 函数中调用才有意义。如果在普通代码流程中直接调用 recover,它会返回 nil。
示例:func safeDivide(a, b int) (result int, ok bool) {
defer func() {
if r := recover(); r != nil {
result = 0
ok = false
}
}()
if b == 0 {
panic("division by zero")
}
return a / b, true
}
这个例子中,recover 成功捕获了 panic,程序不会崩溃。
无法捕获的场景
以下情况 recover 无能为力:
- 协程内部的 panic 不会传播到主协程,主协程的 defer/recover 捕获不到子协程的 panic
- 系统级崩溃,如内存耗尽、栈溢出(可能导致程序直接退出)
- 未被 defer 包裹的 panic
常见误解澄清
很多人误以为 recover 类似于其他语言的 try-catch,可以捕获所有异常。实际上 Go 的 error 和 panic 是两种不同的错误处理机制:
- error 用于预期可能出错的情况,需主动检查和处理
- panic 用于不可恢复的错误,应尽量避免滥用
- recover 仅作为最后防线,防止程序整体崩溃
基本上就这些。recover 并非万能,合理使用 error 处理才是 Go 风格的核心。对可预见的错误,优先用 if err != nil 判断,而不是依赖 panic 和 recover。
火山引擎是字节跳动旗下企业级云与AI服务平台。聚焦大模型核心能力,依托字节自研豆包多模态大模型,凭借火山方舟一站式平台,提供模型精调、推理部署、智能应用搭建等全链路服务,结合高性能AI算力,助力各行业快速落地大模型数字化与智能化应用。
















