Go通过panic和recover机制捕获运行时错误，recover仅在defer函数中有效，可将异常转为error处理；在Web服务中常通过中间件全局捕获panic，防止程序崩溃；但recover无法捕获子goroutine或系统级故障引发的panic。
在Go语言中，捕获运行时错误主要依赖于panic和recover机制。正常情况下，Go推荐使用error作为函数返回值来处理可预期的错误，而panic用于不可恢复的严重错误。但某些场景下，程序可能因数组越界、空指针解引用等触发运行时异常，这时可以通过defer结合recover来捕获并恢复程序执行。
使用 defer 和 recover 捕获 panic
recover是一个内建函数，只能在defer修饰的函数中生效，用于重新获得对panic的控制权，并返回panic传入的值。若没有发生panic，recover返回nil。
基本用法如下：
func safeDivide(a, b int) (result int, err error) {
defer func() {
if r := recover(); r != nil {
err = fmt.Errorf("运行时错误: %v", r)
}
}()
result = a / b
return result, nil
}
在这个例子中，当b为0时，除零操作会触发panic，但由于有defer中的recover，程序不会崩溃，而是将错误转为普通error返回。
立即学习“go语言免费学习笔记（深入）”；
在 Web 服务中全局捕获 panic
在HTTP服务中，某个处理函数如果发生未处理的panic，会导致整个服务中断。因此通常会在中间件中加入恢复机制。
例如：
func recoverMiddleware(next http.HandlerFunc) http.HandlerFunc {
return func(w http.ResponseWriter, r *http.Request) {
defer func() {
if r := recover(); r != nil {
log.Printf("请求发生panic: %v", r)
http.Error(w, "服务器内部错误", 500)
}
}()
next(w, r)
}
}
通过包装处理函数，确保即使某个请求触发了运行时错误，也不会影响其他请求。
recover 的使用限制
recover只有在defer函数中调用才有效。以下几种情况无法捕获：
对于协程中的panic，需要在每个goroutine内部单独做recover处理：
go func() {
defer func() {
if r := recover(); r != nil {
log.Println("协程中发生panic:", r)
}
}()
// 可能 panic 的操作
}()
基本上就这些。Go的设计哲学是尽量避免使用panic作为控制流，但在库或框架中，适当使用recover可以提升健壮性。关键是理解它只应对真正意外的运行时错误，而不是替代正常的错误处理逻辑。
