panic和recover是Go中用于处理严重错误的机制，通过panic触发异常并中断函数执行，随后在defer中利用recover捕获并恢复程序流程，防止崩溃。常见触发场景包括主动调用panic、数组越界、nil指针解引用等。recover仅在defer中有效，可获取panic值并进行日志记录或错误响应，适用于Web中间件全局捕获异常，但不应替代常规error处理，避免滥用以确保代码可维护性。
在Go语言中，panic和recover是用于处理严重错误的机制，它们不是常规的错误处理方式（应优先使用error返回值），而是在程序遇到无法继续执行的异常情况时提供一种“紧急退出+恢复”的手段。合理使用panic和recover可以提升程序的健壮性，但滥用会导致代码难以维护。
理解 panic 的触发与行为
当调用 panic 时，当前函数执行停止，并开始逐层回溯调用栈，执行延迟函数（defer）。这个过程持续到程序崩溃，除非被 recover 捕获。
常见触发 panic 的场景包括：
- 主动调用 panic("something went wrong")
- 数组越界访问
- nil 指针解引用
- 类型断言失败（如 v := i.(int)，i 不是 int 类型）
func badFunction() {
panic("oh no, something failed!")
}
使用 recover 捕获 panic
recover 是一个内置函数，只能在 defer 函数中有效调用。它能中止 panic 的传播并返回传给 panic 的值。
立即学习“go语言免费学习笔记（深入）”；
关键点：
- recover 必须在 defer 中调用才有效
- recover 返回 interface{} 类型，需根据需要进行类型断言
- recover 后程序不会回到 panic 点，而是继续执行 defer 之后的逻辑
func safeCall() {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered:", r)
}
}()
badFunction() // 触发 panic
fmt.Println("这条不会打印")
}
实际应用场景：Web 服务中的全局异常捕获
在 HTTP 服务中，某个处理函数发生 panic 会导致整个服务中断。通过中间件结合 recover 可防止服务崩溃。
示例：HTTP 中间件保护 handlerfunc recoverMiddleware(next 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", 500)
}
}()
next(w, r)
}
}
func handler(w http.ResponseWriter, r *http.Request) {
panic("unexpected error in handler")
}
注册路由时使用：
http.HandleFunc("/bad", recoverMiddleware(handler))
注意事项与最佳实践
虽然 panic 和 recover 强大，但应谨慎使用：
- 不要用 recover 替代错误处理。普通错误应通过 error 返回
- 库函数尽量避免 panic，除非调用方明显误用 API
- 在 defer 中调用 recover 后，可根据需要记录日志或发送监控信号
- recover 后通常不应继续原有逻辑，而应返回安全默认值或错误响应
基本上就这些。panic 和 recover 是 Go 提供的最后防线机制，适合在不可恢复错误发生时优雅收场，而不是日常流程控制工具。正确使用能让系统更稳定，滥用则会让调试变得困难。
