recover不能单独基准测试，必须构造panic+defer+recover完整链路；recover须在defer中调用，且panic需真实发生（如panic("test")），才能测出实际恢复开销。
recover本身不能被单独基准测试
直接写 BenchmarkRecover 测 recover() 调用耗时是无效的。因为 recover 只在 panic 状态下有意义，且它的行为依赖于当前 goroutine 的 _panic 链状态——你无法在无 panic 的上下文中“合法”调用它并得到非 nil 结果。强行测会返回 nil，测出来的只是空分支开销，和真实场景无关。
必须构造 panic + defer + recover 的完整链路
真正要评估的是「从 panic 触发 → defer 执行 → recover 捕获 → 恢复执行」这一整条路径的代价，这才有生产参考价值。关键点：
- panic 必须真实发生（不能用
recover()单独测） - recover 必须在 defer 函数中调用（否则永远返回 nil）
- 基准函数里不能提前 return，否则 defer 不会触发
- 要排除 panic 本身（如越界、空指针）的额外开销，统一用
panic("test")
示例写法：
func BenchmarkPanicRecover(b *testing.B) {
for i := 0; i < b.N; i++ {
func() {
defer func() {
if r := recover(); r != nil {
// 忽略，只计时
}
}()
panic("test")
}()
}
}
对比基线：不 recover 的 panic 开销
recover 的“净开销”需要减去 panic 本身的成本。所以必须配一个对照组：
3-Tier Auto-Backup Daily Snapshots, Drive Mirror & Emergency Recovery
下载
三层自动备份：每日时间戳快照、次级硬盘镜像、紧急对话导出。
立即学习“go语言免费学习笔记（深入）”；
func BenchmarkPanicOnly(b *testing.B) {
for i := 0; i < b.N; i++ {
func() {
defer func() {
// 不调 recover，仅触发 defer
}()
panic("test")
}()
}
}
两组结果相减（ns/op 差值）才接近 recover 的实际贡献。注意：这个差值通常很小（几纳秒），但会在高频率 panic 场景（如错误注入测试）中放大。
容易踩的坑：逃逸、内联、GC 干扰全得关掉
recover 相关逻辑极易受编译器优化干扰：
- 闭包捕获变量（如
defer func(){ recover() }()）会触发逃逸，测出来的是堆分配成本，不是 recover 本身 - 函数太小可能被内联，导致 panic/recover 路径被优化掉——加
//go:noinline到外层匿名函数上 - 默认
go test -bench不触发 GC，而 panic 会快速堆积 _panic 结构体，影响后续轮次；应加-count=5 -benchtime=3s并人工剔除首尾离群值 - 别用
b.ReportAllocs()期待看到 recover 分配——它不分配内存，但 panic 链会，所以 allocs/op 差异反映的是 panic 管理结构体生命周期，不是 recover
最可靠的信号是：两组 benchmark 的 ns/op 差值稳定在 2–8 ns 区间，且 allocs/op 完全一致，说明你测到的是 recover 的纯调用判断开销，而非其他噪声。
