Golang panic捕获与异常处理方法

Go 语言中 panic 表示不可恢复的严重错误，recover 仅能在 defer 中且仅对同 goroutine 的 panic 有效，不能拦截 error；正确用法是在 HTTP handler 等外层加 defer+recover 防止服务崩溃。

Go 语言没有传统意义上的“异常捕获”机制（比如 Java 的 try/catch 或 Python 的 try/except），panic 不是用于常规错误处理的工具，而是表示**不可恢复的严重错误**，比如空指针解引用、切片越界、调用 panic() 显式中断等。你无法用 panic “捕获异常”来继续执行逻辑——它默认会终止当前 goroutine，并向上冒泡直至程序崩溃。

为什么不能用 recover 拦截任意错误

recover 只能在 defer 函数中、且仅在当前 goroutine 发生 panic 时才有效。它不是全局异常处理器，也不能拦截 error 值（比如 os.Open 返回的 error）。

• recover() 必须紧贴在 defer 调用内，且该 defer 必须在 panic 触发前已注册
• 一旦 panic 发生，当前函数立即停止执行，后续语句（包括其他 defer）按栈逆序执行
• recover() 只对本 goroutine 有效；主 goroutine 中 panic 未被 recover，整个程序退出

正确使用 recover 阻止 panic 波及主流程

典型场景：在 HTTP handler 或长期运行的 goroutine 中防止一个 panic 导致整个服务宕机。关键在于把 recover 放进最外层 defer，并确保它在 panic 后能拿到 panic 值。

func safeHandler() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("panic recovered: %v", r)
            // 这里可记录日志、上报指标、返回 fallback 响应等
        }
    }()
    // 可能 panic 的代码，例如：
    _ = []int{1, 2}[5] // slice bounds out of range
}

• 必须用 func() { ... }() 立即执行匿名函数，否则 defer 注册的是函数字面量而非调用结果
• recover() 返回 interface{}，需类型断言才能获取原始 panic 值（如 r.(string) 或 fmt.Sprintf("%v", r)）
• 不要在 defer 里直接写 recover()（如 defer recover()），它不会生效

panic 和 error 的分工必须清晰

绝大多数业务错误（文件不存在、网络超时、参数校验失败）应该返回 error，而不是触发 panic。滥用 panic 会让调用方失去控制权，也违背 Go 的显式错误处理哲学。

• panic 适合：程序启动失败（配置加载异常）、不可恢复的内部状态（如 mutex 已解锁却再次 unlock）、断言失败（assert 类逻辑）
• error 适合：所有可预期、可重试、可降级的失败场景
• 第三方库若内部用了 panic（如某些正则匹配库对非法 pattern 的处理），你只能靠外层 recover 拦截，但这是防御性措施，不是设计常态

goroutine 中 panic 的 recover 容易漏掉

新起的 goroutine 是独立的执行单元，主 goroutine 的 defer/recover 对它完全无效。每个可能 panic 的 goroutine 都要自己加保护。

go func() {
    defer func() {
        if r := recover(); r != nil {
            log.Printf("worker goroutine panicked: %v", r)
        }
    }()
    doSomethingRisky()
}()

漏掉这个，就是典型的“后台任务 panic 导致进程静默退出”，日志里只有一行 fatal error: all goroutines are asleep - deadlock? 或直接消失——因为 panic 后 goroutine 终止，又没其他 goroutine 推进，主函数提前退出。