recover应谨慎使用，避免掩盖错误。推荐将panic转为error返回、定义可识别异常类型、限制recover范围，并在调试模式下记录完整堆栈，确保错误可追溯、可分类、可响应，提升系统可靠性与可维护性。
在Go语言中，recover常被用来捕获panic，防止程序崩溃。但滥用或不当使用recover，很容易掩盖真实的错误信息，导致调试困难、线上问题难以定位。尤其在中间件、框架或公共库中，如果不加控制地recover所有panic，可能让调用者误以为一切正常，实则已发生严重错误。
问题根源：recover吞掉关键错误信息
常见的错误做法是在defer函数中无差别地调用recover：
defer func() {
if r := recover(); r != nil {
log.Println("recovered:", r)
}
}()
这种写法虽然避免了
程序崩溃，但也把panic的堆栈、类型、上下文全部丢弃，调用方无法感知异常，日志也缺乏细节，不利于排查。
方案一：恢复panic并重新抛出为error
更合理的做法是将panic转换为error返回，保持错误可传递性：
func safeDivide(a, b int) (int, error) {
var result int
var panicErr error
defer func() {
if r := recover(); r != nil {
panicErr = fmt.Errorf("panic occurred: %v", r)
// 可选：记录堆栈
buf := make([]byte, 4096)
runtime.Stack(buf, false)
log.Printf("stack trace: %s", buf)
}
}()
result = a / b
return result, panicErr
}
这样调用方可以通过error判断是否发生异常，同时保留了原始panic信息和堆栈，便于追踪。
方案二：定义可识别的异常类型
对于业务中可预期的“异常流程”，建议定义专用错误类型，避免使用panic：
type AppError struct {
Msg string
Code int
}
func (e *AppError) Error() string {
return fmt.Sprintf("[%d] %s", e.Code, e.Msg)
}
当必须使用panic时（如插件机制），可通过recover识别特定类型并转换：
defer func() {
if r := recover(); r != nil {
if appErr, ok := r.(*AppError); ok {
err = appErr // 转换为普通error
} else {
// 非预期panic，应记录并上报
log.Panic(r) // 或使用sentry等工具
}
}
}()
方案三：限制recover的作用范围
不要在整个服务入口处“兜底式”recover。应在最小必要范围内使用，例如：
- RPC handler中recover网络层panic，但不处理业务逻辑错误
- 插件加载时隔离第三方代码的崩溃
- 定时任务中防止单个任务失败影响整体调度
每个recover点都应明确目的，并附带上下文日志。
方案四：启用调试模式记录完整堆栈
在开发或预发环境，可开启详细panic日志：
debugMode := true
defer func() {
if r := recover(); r != nil {
log.Printf("PANIC: %v", r)
if debugMode {
log.Printf("Stack:\n%s", debug.Stack())
}
// 根据环境决定是否重新panic
if !debugMode {
err = fmt.Errorf("%v", r)
} else {
panic(r) // 开发期快速暴露问题
}
}
}()
Go的错误处理本就不依赖异常机制，过度使用panic+recover会破坏代码的可读性和可靠性。真正透明的异常处理，不是隐藏错误，而是让错误可追溯、可分类、可响应。合理使用recover，将其作为最后防线而非常规流程控制手段，才能做到“异常透明化”。基本上就这些。
