本文详解 go 语言中 recover 机制在 main 函数与测试函数（如 testxxx）中表现一致，而“err 为 nil”或“非 nil”的差异实则源于误用 fmt.errorf 导致的逻辑错觉——它不输出也不改变程序流，仅构造 error 值，需改用 fmt.printf 才能观察实际恢复结果。
本文详解 go 语言中 recover 机制在 main 函数与测试函数（如 testxxx）中表现一致，而“err 为 nil”或“非 nil”的差异实则源于误用 fmt.errorf 导致的逻辑错觉——它不输出也不改变程序流，仅构造 error 值，需改用 fmt.printf 才能观察实际恢复结果。
在 Go 中，recover() 的行为与执行环境（main 或 test）无关，只要 defer 链完整、panic 发生在被 defer 包裹的函数内，recover 就能成功捕获 panic 并赋值给 error 变量。你观察到的“main 中 err 为 nil，test 中 err 非 nil”，并非运行时机制差异，而是代码逻辑缺陷导致的误判。
关键问题出在 main 函数中的这一行：
fmt.Errorf("Error: %v", err) // ❌ 错误：仅构造 error，不打印、不赋值、无副作用fmt.Errorf 是一个纯函数：它根据格式化字符串和参数生成一个新的 error 值并返回，但该返回值未被接收或使用。因此，即使 err != nil，这行代码也完全不会输出任何内容，更不会影响后续流程——你误以为“没触发错误处理”，实则是“错误已被捕获，但你没看到”。
而测试函数中使用的 t.Errorf(...) 是测试框架提供的断言辅助方法，它会自动打印日志并标记测试失败，因此你能直观看到 err 的真实值（例如 runtime error: index out of range [0] with length 0），从而误以为“test 能捕获，main 不能”。
✅ 正确写法（统一适用于 main 和 test）：
if err := fp.Panic(); err != nil {
fmt.Printf("Recovered panic: %v\n", err) // ✅ 使用 fmt.Printf 输出可观测结果
}或在测试中保持原样（因其本身具备输出能力）：
func TestPanic(t *testing.T) {
fp := &Foo{}
if err := fp.Panic(); err != nil {
t.Errorf("Panic: %v", err) // ✅ 正确：t.Errorf 会打印并记录
}
}此外，你的 PanicRecovery 函数可进一步健壮化：无需区分 runtime.Error，因为所有 panic 值（包括字符串、int、error 等）都可通过 r.(error) 断言——前提是 panic 值本身实现了 error 接口。但注意：若直接 panic("oops")，r 是 string 类型，强制转 error 会 panic。更安全的写法是：
func PanicRecovery(err *error) {
if r := recover(); r != nil {
switch e := r.(type) {
case error:
*err = e
case string:
*err = errors.New(e)
default:
*err = fmt.Errorf("panic: %v", e)
}
}
}总结：Go 的 panic/recover 机制在 main 和 test 中行为完全一致；所谓“差异”本质是开发调试中常见的副作用误解。牢记：fmt.Errorf ≠ 输出，fmt.Printf / log.Print / t.Error* 才是可观测的入口。编写错误处理逻辑时，始终验证变量值（如加 fmt.Println("err =", err)），而非依赖未消费的函数调用。
