panic/recover 开销远高于普通 error 返回，因栈展开、goroutine 快照等操作导致吞吐量或降百倍；error 返回仅指针传递，近乎零开销。
panic/recover 的开销远高于普通 error 返回
是的，panic/recover 会显著拖慢程序性能，尤其在高频路径中——实测吞吐量可能下降 100 倍以上。这不是理论推测，而是 Go 运行时栈展开、goroutine 状态快照、调用链构造等动作带来的真实代价。
-
error接口返回只是指针传递 + 接口赋值，几乎零开销 -
panic触发后，运行时必须逐层 unwind 栈帧，每个defer都要检查是否含recover，过程不可省略 -
recover成功后虽能继续执行，但已付出完整 panic 路径的成本，无法“抵消”开销 - 单次
defer开销在纳秒级，但若在循环里每轮都panic再recover，就等于把异常路径跑成了主路径
哪些场景下用 panic/recover 是合理且低风险的
它不是错误处理的替代品，而是“兜底安全网”，只应在极少数、真正不可恢复或框架级防护场景使用。
- 服务启动阶段：如
mustOpenFile读取关键配置失败，程序本就不该存活 - HTTP 中间件：用
defer+recover捕获 handler 内部 panic，避免单个请求搞垮整个服务 - 测试模拟崩溃：验证日志、监控或清理逻辑是否生效
- 类型断言/强制转换等“本不该发生”的情况（例如
v, ok := x.(MyType)后!ok却继续解引用）
注意：recover 必须写在 defer 注册的函数体内，写在普通代码块里永远返回 nil。
常见误用：把业务错误当 panic 处理
这是最典型的性能与可维护性双杀操作。比如除零、参数校验失败、数据库查不到记录……这些全属可预期、可重试、可提示用户的常规错误，应走 error 返回路径。
立即学习“go语言免费学习笔记（深入）”；
- ❌ 错误写法：
if b == 0 { panic("division by zero") }—— 每次被调用都可能触发栈展开 - ✅ 正确写法：
if b == 0 { return 0, errors.New("division by zero") }—— 零成本，调用方明确感知 - 滥用
panic会让调用链失去控制流语义，调试时分不清是 bug 还是设计如此 - 子 goroutine 中的
panic不会被外层recover捕获，容易漏掉静默崩溃
想安全又高效？优先封装 safeRun，而非裸写 recover
直接在每个函数里手写 defer func() { recover() }() 容易遗漏、重复、难统一。更可控的做法是抽象一层通用兜底包装。
func safeRun(f func()) {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered in safeRun: %v", r)
}
}()
f()
}
- 调用时只需
safeRun(func() { riskyOperation() })，逻辑清晰、复用性强 - 便于集中添加日志、指标上报、错误分类等增强能力
- 避免在 hot path（如 HTTP handler 主体）里嵌套多层
defer+recover - 仍需记住：
recover后不会回到 panic 发生点继续执行，函数直接返回，状态不会自动回滚
真正影响性能的从来不是某一行代码，而是你把「异常」当「常态」来设计。Go 的哲学很直白：error 是值，panic 是事故。别让事故变成日常。
