在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 函数中被触发。
举个例子：
立即学习“go语言免费学习笔记（深入）”；
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 + 日志记录 + 清理资源 —— 正确姿势。
基本上就这些。用得少但关键时刻能救命，别滥用就行。
