Golang panic与recover如何正确配合使用

在Go语言中，panic和recover用于处理运行时异常，但不能作为常规错误处理手段。正确使用需遵循以下要点：1. recover必须通过defer调用才能捕获panic；2. panic触发后会立即停止当前函数执行并按LIFO顺序执行defer函数；3. 若defer中未正确recover或无defer，panic将向上层传播导致程序崩溃；4. 使用场景包括初始化错误、第三方库非法输入提醒等关键点；5. 注意事项包括避免频繁使用、recover后应记录日志而非静默忽略、库函数应明确文档说明是否会panic；6. 常见误区有非defer中调用recover、跨函数recover无效、滥用panic模拟try/catch结构。

在Go语言中，panic 和 recover 是处理运行时异常的机制，但它们不是用来做常规错误处理的工具。正确使用这两个函数，可以让你在程序出现严重问题时优雅地恢复执行流程，而不是直接崩溃。关键在于：只有在函数内部通过 defer 调用 recover 才能捕获到 panic 引发的异常。

defer 是 recover 正常工作的前提

recover 只有在被 defer 调用的函数中才能生效。如果你在普通函数调用里直接使用 recover，它不会起作用。这是因为 recover 的设计初衷是用于捕获当前 goroutine 中正在发生的 panic，并且只能在 defer 函数中被触发。

举个例子：

func badExample() {
    if r := recover(); r != nil {
        fmt.Println("Recovered:", r)
    }
}

func main() {
    badExample()
}

上面这段代码中的 recover() 是无效的，因为没有发生 panic，也没有 defer。正确的做法应该是：

func safeFunc() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered in defer:", r)
        }
    }()

    panic("something went wrong")
}

panic 触发后控制流程会中断

一旦调用了 panic，当前函数的执行就会立即停止，然后开始执行所有已经注册的 defer 函数（按 LIFO 顺序）。如果这些 defer 函数中没有调用 recover，或者 recover 没有起作用，那么 panic 会继续向上层调用栈传播，最终导致整个程序崩溃。

所以你需要注意：

• 不要在不必要的情况下使用 panic。
• 如果你打算 recover，就一定要在同一个函数中设置 defer。
• recover 后你可以选择记录日志、清理资源、返回错误等操作。

实际使用场景和建议

虽然 panic 不应该作为正常错误处理流程的一部分，但在某些情况下它是有用的：

• 在初始化阶段发现不可恢复错误时主动 panic，比如配置加载失败。
• 第三方库中遇到非法输入或状态时，主动 panic 提醒使用者。
• 避免更复杂的错误传递逻辑，在顶层统一 recover 并记录日志。

但要注意以下几点：

• 尽量避免在业务逻辑中频繁使用 panic。
• recover 后不要静默忽略，最好记录日志或通知监控系统。
• 如果你在写库，要明确文档说明是否会 panic，以及用户应该如何处理。

总结一下常见误区

• ❌ 在非 defer 函数中调用 recover —— 不起作用。
• ❌ 在上层函数 recover 子函数的 panic —— 无法跨函数 recover。
• ❌ 把 panic 当作 try/catch 使用 —— Go 不鼓励这种做法。
• ✅ 在 defer 中 recover + 日志记录 + 清理资源 —— 正确姿势。

基本上就这些。用得少但关键时刻能救命，别滥用就行。