recover()在defer中总返回nil，因其仅在panic发生且当前goroutine处于defer执行时有效；跨goroutine、非匿名函数调用或panic已结束时均无效。
defer 里调用 recover() 为什么总是返回 nil
因为 recover() 只在 panic 正在发生、且当前 goroutine 处于 defer 链执行过程中时才有效。如果 defer 函数本身没在 panic 的栈帧内被调度（比如 panic 发生在另一个 goroutine，或 defer 已执行完毕），recover() 就只能返回 nil。
常见错误是把 recover() 写在非直接 defer 的函数里：
func bad() {
defer func() {
log.Println(recover()) // ✅ 正确位置
}()
defer helper() // ❌ helper 里调用 recover() 一定返回 nil
}
func helper() {
recover() // 永远 nil：此时 panic 尚未开始，或已结束
}
- 必须用匿名函数包裹
recover()，确保它和panic()处于同一 goroutine 的 defer 执行上下文 - 不能跨 goroutine 捕获 panic：启动新 goroutine 后发生的 panic，主 goroutine 的 defer 看不见
- 多个 defer 会按后进先出顺序执行，
recover()必须在最靠近 panic 的那个 defer 里调用才可能生效
recover() 能捕获哪些 panic 类型
recover() 可以捕获任意类型值的 panic，包括 nil、string、自定义 error、结构体甚至函数——只要 panic() 的参数是合法 Go 值。
但要注意：如果 panic 的值是 nil，recover() 返回的也是 nil，这时无法区分“没 panic”和“panic(nil)”。实际中应避免 panic(nil)。
立即学习“go语言免费学习笔记（深入）”；
-
panic("oops")→recover()返回"oops"（interface{}类型） -
panic(errors.New("io failed"))→ 返回对应 error 接口值 -
panic(42)→ 返回42，需用类型断言提取：v, ok := recover().(int) - 若不确定类型，建议统一转为
error：用fmt.Errorf("panic: %v", r)包装
defer + recover 的典型安全封装模式
最常用的是在 HTTP handler 或长周期任务入口处加一层 panic 拦截，防止整个 goroutine 崩溃。关键点是：必须在同一个函数内完成 defer + recover，且不能漏掉类型处理。
func safeHandler(f http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
f(w, r)
}
}
- 不要在 defer 中直接写
log.Fatal()或os.Exit()，这会终止整个进程 - 如果需要记录堆栈，用
debug.PrintStack()或runtime/debug.Stack() - 注意 defer 的作用域：它只对当前函数生效；嵌套函数调用中的 panic 不会被外层函数的 defer 捕获，除非 panic 发生在 defer 执行期间
- HTTP server 默认不 recover panic，不加这层封装，panic 会导致连接直接断开且无响应
recover 后程序还能继续运行吗
可以，但仅限当前 goroutine 的当前函数及调用栈上层未返回的部分。recover() 只是让 panic 停止传播，并不“回滚”已发生的副作用。
- 已修改的全局变量、已写入的文件、已发送的 channel 数据，都不会自动撤销
- recover() 后函数会从 defer 结束处继续向下执行（不是回到 panic 那一行）
- 如果想模拟“重试”或“降级”，需手动控制流程，比如用 for 循环 + 错误标记
- 在 defer 中 recover 后，仍可 return 正常值；但如果 panic 发生在 defer 里（比如 defer 函数自己 panic），则无法再 recover
真正难处理的从来不是 recover 能不能用，而是 panic 发生后状态是否一致、资源有没有泄漏、下游服务是否已收到部分请求——这些得靠设计，不是靠 defer 补救。
