在Go语言开发中，panic代表不可恢复的运行期异常，一旦触发且没有处理，就会沿着调用栈向上抛直至程序崩溃。为了不让单个协程的崩溃影响整体服务，我们可以利用defer和recover机制，在合适的层级把panic拦截下来，并转换成普通的error返回，从而实现更优雅的错误处理。
defer与recover的基本原理
defer用来延迟执行一个函数调用，被延迟的函数会在当前函数返回之前按照后进先出的顺序执行。recover是一个内置函数，用于停止panic过程并获取panic传入的值。关键点在于，recover只有在defer调用的函数体中直接调用才有效，如果在嵌套函数或普通逻辑中调用，它只会返回nil。
当panic被recover捕获后，原本的panic流程会被中止，当前函数恢复正常返回，程序也不会退出。这种机制类似于其他语言中的try-catch，但Go官方推荐只在真正异常的场景使用，而不是用来代替常规的error返回。理解这一点，才能避免滥用导致代码可读性下降。
最小可用示例
下面这段代码展示了在最基础的层面捕获panic并转成错误：
package main
import (
"errors"
"fmt"
)
func mayPanic() (err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("捕获到panic: %v", r)
}
}()
panic("something wrong")
}
func main() {
err := mayPanic()
if err != nil {
fmt.Println(err)
} else {
fmt.Println("正常结束")
}
}
在上面的例子中，mayPanic函数通过defer匿名函数调用recover，当panic发生时会将返回值err赋值为一个包含信息的错误。这样main函数就能像处理普通错误一样判断结果，而程序不会异常退出。
封装通用的panic捕获辅助函数
在真实项目中，我们往往希望在多个业务函数里复用同一套捕获逻辑，同时保留堆栈以便排查问题。可以封装一个工具函数，在defer中统一处理，并把recover得到的异常包装为带上下文的error。
需要注意，recover拿到的值可能是任意类型，不一定是error，所以用fmt.Errorf做一层格式化会更安全。如果希望记录调用栈，可以结合runtime包获取更详细的信息，但这会带来一定性能开销，仅在关键服务中使用较为合适。
带堆栈的封装写法
package util
import (
"fmt"
"runtime/debug"
)
func CatchPanic(operation string) func() {
return func() {
if r := recover(); r != nil {
stack := debug.Stack()
fmt.Printf("操作%s发生panic: %vn堆栈: %sn", operation, r, stack)
}
}
}
func DoBusiness() (err error) {
defer CatchPanic("DoBusiness")()
// 模拟业务中的意外崩溃
panic("db connection lost")
}
这里CatchPanic返回一个闭包，在defer时立即调用，既满足了recover的直接调用要求，也把操作名称传进去方便日志区分。DoBusiness里即使panic，也会被捕获并打印堆栈，而不会让进程直接死掉。
在HTTP服务中转换panic为错误响应
Web服务是panic防护的重点场景。一个未捕获的panic会让整个HTTP服务挂掉，因此通常在中间件或handler入口用defer加recover拦截，然后把异常转为500错误或结构化错误体返回。
这种做法能保证单个请求失败不影响其他请求，同时也给前端明确的错误信息。不过要注意，如果在recover之后还需要写响应，必须确保ResponseWriter还没有被部分写入，否则可能产生不完整的响应。
简单中间件示例
package main
import (
"fmt"
"net/http"
)
func RecoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
w.WriteHeader(http.StatusInternalServerError)
fmt.Fprintf(w, "内部错误: %v", r)
}
}()
next.ServeHTTP(w, r)
})
}
func hello(w http.ResponseWriter, r *http.Request) {
panic("unexpected")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/hello", hello)
http.ListenAndServe(":8080", RecoverMiddleware(mux))
}
以上中间件在每个请求处理前注册了defer，当hello处理器panic时，recover会捕获并写回500状态码和错误文本。这样即使某个接口写出问题代码，服务依然可以继续监听端口处理后续流量。
常见误用与注意边界
很多初学者会把recover写在普通函数里，或者包在一层内部函数中，结果永远拿不到panic值。记住，recover必须出现在defer后面直接跟的函数体第一层，不能间接调用。
另一个边界是，recover无法跨协程捕获panic。如果你在go func()里panic，外部函数的defer recover是拦不到的，必须在子协程内部自己加defer recover。此外，panic转error适合防御性兜底，不应作为日常控制流，否则会掩盖真正的代码缺陷。
协程内捕获示例
package main
import (
"fmt"
"time"
)
func worker() {
defer func() {
if r := recover(); r != nil {
fmt.Println("worker recover:", r)
}
}()
panic("goroutine panic")
}
func main() {
go worker()
time.Sleep(time.Second)
fmt.Println("main exit")
}
这段程序在子协程worker中自行defer recover，主协程睡眠一秒等待其执行完毕，最终worker内的panic被自己消化，主程序平稳退出。如果去掉worker里的defer，程序就会因未捕获panic而直接崩溃。
总结与最佳实践
通过defer和recover把panic转为error，是Go语言中保障服务健壮性的重要手段。建议在服务边界如HTTP中间件、任务调度入口统一加recover，而在内部函数优先使用显式error返回。
实际编码时，捕获到panic应记录足够日志，包括值和堆栈，并将错误向上传递或返回结构化响应。避免在每个小函数里都写recover，以免代码杂乱且性能受损。只要用对位置、理清边界，就能用很低的成本把不可控崩溃变成可控错误。