recover只能在defer调用的函数中生效，且应仅在服务入口、中间件或goroutine启动函数中使用。具体包括：1. 在http中间件中统一捕获panic，防止整个服务崩溃；2. 在goroutine中包裹defer recover，防止子协程panic导致主流程退出；3. 避免在业务逻辑中滥用recover，不应代替常规错误处理；4. 使用时需注意recover必须直接在defer中调用，不可提前求值，同时应对返回值做类型断言以便分类处理。
在Go语言中，panic 和 recover 是处理运行时异常的机制，但它们并不是用来替代错误处理的常规手段。想要“优雅”地处理 panic，关键在于理解 recover 的使用场景，并在合适的地方调用它。
直接说重点：recover 只能在 defer 调用的函数中生效，且只应在必要的地方（如中间件、服务入口）捕获 panic，避免滥用。
什么是 panic 和 recover？
在 Go 中，当程序遇到严重错误（比如数组越界、空指针访问等），会触发 panic，导致程序崩溃并打印堆栈信息。这时候如果想阻止程序终止，就需要用到 recover。
立即学习“go语言免费学习笔记（深入）”；
-
panic：主动或被动触发程序崩溃。 -
recover：尝试恢复由 panic 引发的程序流程。
需要注意的是，recover 必须配合 defer 使用，否则无效。
举个简单例子：
func demo() {
defer func() {
if r := recover(); r != nil {
fmt.Println("Recovered:", r)
}
}()
panic("something went wrong")
}上面的例子会在 panic 触发后被 defer 捕获，从而输出 "Recovered: something went wrong"。
recover 应该在哪些场景下使用？
虽然 recover 可以让程序继续运行，但不是所有地方都应该使用它。以下是一些推荐使用 recover 的典型场景：
✅ 1. 在服务启动入口或中间件中统一捕获
例如，在 HTTP 服务中，你希望即使某个 handler 出现 panic，整个服务也不会挂掉。可以写一个中间件来包裹 handler：
func safeHandler(fn http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
fn(w, r)
}
}这样做的好处是：
- 避免因为某个请求出错导致整个服务崩溃；
- 统一处理 panic，提升健壮性；
- 不影响其他正常请求。
✅ 2. 在 goroutine 启动函数中保护子协程
goroutine 中发生的 panic 如果不处理，会导致整个程序退出。所以在开启新协程时，建议包裹一层 defer recover：
go func() {
defer func() {
if r := recover(); r != nil {
log.Println("Recovered from goroutine panic:", r)
}
}()
// do something that might panic
}()这种做法尤其适用于异步任务、后台 worker 等不可控逻辑。
❌ 不推荐使用的场景
- 业务逻辑中频繁使用 recover 来代替 if err != nil
- 在非关键路径上捕获 panic，比如一个简单的数据转换函数也加 defer recover
- 捕获后不做任何记录或处理，只是“吞掉”异常
这些做法会让代码难以维护，掩盖真正的错误。
recover 使用注意事项
有几个细节非常容易忽略，但会影响 recover 是否生效：
-
必须在 defer 中直接调用 recover
下面这个写法不会起作用：defer func() { fmt.Println(recover()) // 正确 }()而下面这个写法不会生效：
defer func(r interface{}) { fmt.Println(r) }(recover())因为 recover 在 defer 表达式求值阶段就已经执行了，此时还没发生 panic，recover 返回 nil。
不要嵌套 defer 太深
如果你在多个层级都用了 defer recover，可能会导致 panic 被多次捕获，反而不容易定位问题。-
recover 返回的类型是 interface{}，需要做类型断言
如果你想区分不同的 panic 原因，记得进行类型判断：if r := recover(); r != nil { switch v := r.(type) { case string: fmt.Println("Panic message:", v) case error: fmt.Println("Panic error:", v) default: fmt.Println("Unknown panic:", v) } }
总结一下
recover 的本质是用来兜底的最后防线，而不是解决错误的根本手段。它的正确打开方式包括：
- 在服务入口统一捕获 panic
- 在 goroutine 中防止协程崩溃拖累主流程
- 配合 defer 使用，注意调用方式和类型处理
基本上就这些。用好了 recover，能让系统更稳定；但别把它当成万能药。
