如何在Golang中捕获运行时异常_Golangpanic与recover实践_技术教程

panic会中断当前goroutine执行并展开调用栈执行defer，若无recover则程序崩溃；常见场景有nil指针解引用、切片越界、向已关闭channel发送数据。

panic 会中断当前 goroutine 的执行流程

Go 没有传统意义的“异常”，panic 是一种运行时错误信号，一旦触发，当前 goroutine 会立即停止执行后续语句，并开始向上展开调用栈，依次执行所有已注册的 defer 函数。如果没有任何 recover 拦截，程序最终会崩溃并打印堆栈。

常见触发 panic 的场景包括：

nil 指针解引用（如 var p *int; fmt.Println(*p)）
切片越界访问（如 s := []int{1}; s[5]）
向已关闭的 channel 发送数据（close(ch); ch ）
显式调用 panic("msg")

recover 必须在 defer 中调用才有效

recover 不是全局捕获器，它只在 defer 函数中调用时才有意义，且仅能捕获**当前 goroutine** 中由 panic 引发的中断。如果写成普通函数调用（不在 defer 里），recover 总是返回 nil，起不到任何作用。

正确写法示例：

func safeDivide(a, b int) (result int, err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("panic occurred: %v", r)
        }
    }()
    if b == 0 {
        panic("division by zero")
    }
    result = a / b
    return
}

关键点：

recover() 必须出现在 defer 内部的匿名函数或命名函数中
不能跨 goroutine 恢复：在一个 goroutine 中 panic，另一个 goroutine 中的 recover 无效
恢复后，原函数不会“继续执行”，而是直接返回——因为 panic 已经让控制流跳出到最近的 defer

recover 返回值类型是 interface{}，需类型断言处理

recover() 返回的是 interface{}，实际值取决于 panic 传入的内容。如果是字符串，就用 string(r)；如果是自定义错误，建议统一用 error 类型 panic，便于断言：

panic(fmt.Errorf("invalid input: %s", input))
// recover 后可安全断言为 error
if r := recover(); r != nil {
if err, ok := r.(error); ok {
log.Printf("caught error: %v", err)
} else {
log.Printf("caught non-error panic: %v", r)
}
}

不推荐直接 panic("xxx") 后又想当成 error 处理，因为字符串和 error 是不同底层类型，断言会失败。

其他注意事项：

多次调用 recover() 只有第一次有效，后续都返回 nil
不要滥用 recover 替代正常错误处理，比如本该用 if err != nil 判断的地方，不应靠 panic/recover 拦截
HTTP handler 中常用于兜底防止整个服务因单个请求 panic 而退出，但日志必须记录原始 panic 堆栈（debug.PrintStack()）

goroutine 泄漏与 recover 的边界问题

在启动新 goroutine 的场景下，recover 容易被误认为能“保护主线程”。其实不然：每个 goroutine 独立拥有自己的 panic/recover 生态。主线程中写的 defer + recover 对子 goroutine 中的 panic 完全无感。

例如以下代码无法捕获子 goroutine 的 panic：

func main() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("this will NOT catch the goroutine panic")
        }
    }()
    go func() {
        panic("inside goroutine")
    }()
    time.Sleep(100 * time.Millisecond)
}

真正有效的做法是在子 goroutine 内部加 defer/recover：

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("goroutine recovered: %v", r)
        }
    }()
    panic("inside goroutine")
}()

最容易被忽略的一点：recover 后未做任何处理（比如没记录日志、没返回错误、没通知监控），等于把 panic “静默吞掉”，会让问题更难定位。线上环境务必确保 recover 后至少有明确日志输出。