panic用于处理Go中严重异常，recover必须在defer中调用才能捕获panic并恢复流程；2. 关键业务逻辑可通过defer+recover设置安全屏障，防止程序崩溃；3. 子goroutine需独立设置recover，否则panic会导致整个程序终止；4. 可封装通用WithRecovery函数减少重复代码，提升可维护性。核心是合理使用panic+recover机制，在关键路径兜底但不替代常规错误处理。
在 Go 语言中，panic 和 recover 是处理严重异常的机制，适用于无法继续执行的关键逻辑错误。虽然不推荐用作常规错误处理（应使用 error 返回），但在某些关键流程中合理使用 panic + recover 可防止程序意外崩溃，并保留堆栈信息以便排查问题。
1. 理解 panic 与 recover 的工作机制
当函数调用 panic 时，正常执行流程中断，开始逐层退出当前 goroutine 的函数调用栈，执行延迟语句（defer）。只有在 defer 函数中调用 recover 才能捕获 panic 并恢复正常流程。
recover 必须直接在 defer 函数中调用，否则无效：
func safeDivide(a, b int) (result int, success bool) {
defer func() {
if r := recover(); r != nil {
log.Printf("Recovered from panic: %v", r)
result = 0
success = false
}
}()
if b == 0 {
panic("division by zero")
}
return a / b, true
}
2. 在关键业务逻辑中嵌入 recover 防护
对于可能因外部输入或状态异常导致崩溃的关键路径（如配置解析、核心计算模块），可在入口处设置 defer + recover 安全屏障。
立即学习“go语言免费学习笔记（深入）”；
示例：API 请求处理器中的异常兜底
func handleRequest(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
http.Error(w, "Internal Server Error", 500)
log.Printf("Panic recovered in handler: %v\n%s", err, debug.Stack())
}
}()
processBusinessLogic(r) // 可能 panic 的关键逻辑
}
这样即使内部出错，也能返回友好响应，避免整个服务宕机。
3. 在 Goroutine 中必须单独处理 panic
子 goroutine 中的 panic 不会被父 goroutine 的 defer 捕获，必须在每个独立协程内自行 recover。
常见模式：
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("Goroutine panicked: %v", r)
}
}()
// 可能 panic 的并发任务
doWork()
}()
否则一旦发生 panic，整个程序将终止。
4. 封装通用 recover 工具函数
为减少重复代码，可封装 recover 处理逻辑：
func WithRecovery(fn func()) {
defer func() {
if r := recover(); r != nil {
log.Printf("Recovered: %v", r)
}
}()
fn()
}
// 使用方式
WithRecovery(func() {
criticalOperation()
})
也可扩展支持上下文传递和错误回调，提升灵活性。
基本上就这些。关键是把 recover 放在 defer 中，确保它能运行到，同时不要滥用 panic 来代替错误处理。
