如何从恐慌中恢复过来？

Panic 在 Go 中如同程序“心脏病发作”，recover 可作为“急救工具”防止崩溃，但 recover 仅在 defer 函数中生效。1. recover 用于避免服务挂掉、记录日志、返回友好错误。2. 必须配合 defer 使用，仅对同 goroutine 生效，恢复后程序不回到 panic 点。3. 建议在顶层或关键入口使用，不滥用，优先使用 error 处理。4. 常见模式是封装 safeRun 函数包裹可能 panic 的逻辑。掌握其使用场景与限制，才能正确发挥其作用。

Panic 在 Go 里就像程序突然“心脏病发作”，如果不及时处理，整个流程就可能直接终止。但好在 Go 提供了 recover 这个“急救工具”，可以让你在 panic 发生后尽量稳住程序，不让它崩溃。

不过要注意的是，recover 只能在 defer 调用的函数中生效，不是什么地方都能随便一抓就恢复的。

什么时候该用 recover？

panic 不是错误处理的首选方式，但在某些严重出错、无法继续执行的情况下会触发。这时候你可能想：

• 避免整个服务挂掉（比如 web server 处理请求时）
• 抓住异常并记录日志，方便排查问题
• 返回一个友好的错误信息而不是直接崩溃

这个时候，recover 就派上用场了。特别是在中间件或者全局拦截器中，recover 常用于捕获意外 panic 并做兜底处理。

怎么正确使用 recover 恢复？

recover 的使用有固定套路，基本结构如下：

defer func() {
    if r := recover(); r != nil {
        fmt.Println("Recovered in f", r)
    }
}()

几个关键点要记住：

• 必须配合 defer 使用：recover 必须放在 defer 函数中才有效。
• 只能在同一个 goroutine 中恢复：如果你在一个 goroutine 里 panic，另一个 recover 是抓不到的。
• recover 后程序不会回到 panic 点：程序从 defer 函数返回后继续执行后续逻辑，panic 点之后的代码不会再运行。

举个实际例子：你在处理 HTTP 请求时不小心访问了一个空指针，如果没 recover，整个服务可能崩掉；用了 recover，至少可以把这个请求标记为失败，不影响其他请求。

recover 的局限性和注意事项

虽然 recover 能救命，但它不是万能的，有些情况它也无能为力：

• 不能跨 goroutine 恢复：如果你在子 goroutine 里 panic，主函数的 recover 是看不到的。
• recover 后堆栈已经破坏：虽然程序不崩了，但状态可能已经不一致，需要谨慎处理后续逻辑。
• 不该滥用 recover：它更像是最后防线，不应该用来代替正常的错误检查。

所以建议：

• 尽量只在顶层或关键入口处使用 recover（比如 main 函数、HTTP handler）
• recover 后最好记录详细信息，便于定位问题
• 对于已知可能出错的地方，优先用 error 返回而不是依赖 panic/recover

写 recover 的常见模式

很多项目都会封装一个通用的 recover 函数，比如这样：

func safeRun(fn func()) {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("Recovered: %v", r)
        }
    }()
    fn()
}

然后这样调用：

safeRun(func() {
    // 可能 panic 的代码
})

这种写法在并发任务或定时任务中很实用，可以避免某个任务崩溃导致整体失败。

基本上就这些。recover 不复杂，但容易用错。掌握它的使用场景和限制，才能真正让它发挥价值。

以上是如何从恐慌中恢复过来？的详细内容。更多信息请关注PHP中文网其他相关文章！