Go中panic是严重错误终止机制，测试需可控验证而非避免；可用defer+recover手动捕获（限同goroutine），或用匿名函数+recover精准断言，推荐testify等库简化。
在 Go 中，panic 不是常规错误，而是程序遇到无法恢复的严重问题时的终止机制。单元测试中若不主动捕获 panic，会导致测试直接失败、中断执行，掩盖其他用例问题。要保证测试健壮性，关键不是“避免 panic”，而是**可控地触发并验证 panic 行为是否符合预期**——这正是 testing.T 提供的 test.Panic 检测能力所解决的问题。
使用 recover 手动捕获 panic（适用于非测试逻辑）
在普通业务代码或工具函数中，若需局部处理 panic（如防止 goroutine 崩溃影响主流程），可配合 defer + recover：
-
必须在 panic 发生的同一 goroutine 中 defer，且
recover()要写在defer的匿名函数内 -
recover()只在defer函数执行时有效，且仅能捕获当前 goroutine 的 panic - 不要滥用：仅用于兜底日志、资源清理等场景，不建议用它替代错误返回
示例：
func safeDivide(a, b float64) (float64, error) {
defer func() {
if r := recover(); r != nil {
fmt.Printf("Recovered from panic: %v\n", r)
}
}()
if b == 0 {
panic("division by zero")
}
return a / b, nil
}
在测试中验证 panic 是否按预期发生（推荐方式）
Go 标准测试框架原生支持 panic 断言：testing.T 的 ExpectPanic 并不存在，但可通过 func() { ... }() 匿名函数 + recover 实现精准断言：
立即学习“go语言免费学习笔记（深入）”；
- 将待测函数调用包裹在匿名函数中，并立即执行
- 用
defer + recover捕获 panic 值，再与期望值比对 - 若未 panic，手动调用
t.Fatal报错；若 panic 类型/消息不符，也应失败
示例：
func TestDivideByZeroPanics(t *testing.T) {
var panicked bool
var panicMsg interface{}
func() {
defer func() {
if r := recover(); r != nil {
panicked = true
panicMsg = r
}
}()
divide(10, 0) // 触发 panic 的函数
}()
if !panicked {
t.Fatal("expected panic, but none occurred")
}
if panicMsg != "division by zero" {
t.Errorf("expected panic 'division by zero', got %v", panicMsg)
}
}
使用第三方库简化 panic 断言（如 testify/assert）
若项目已引入 testify，可用其 assert.Panics 或 assert.NotPanics 提升可读性：
assert.Panics(t, func(){ f() }, "should panic on invalid input")-
assert.PanicsWithValue(t, "invalid id", func(){ f(-1) })—— 验证 panic 值精确匹配 - 注意：这些断言底层仍是封装了
recover，本质逻辑一致，只是语法更简洁
避免在测试中全局捕获 panic（反模式）
不要在 TestMain 或顶层 init 中加 recover 来“静默”所有测试 panic：
- 这会让真实 bug 被隐藏，破坏测试的失败即告警原则
- 测试本就该暴露问题；健壮性体现在「明确知道哪里会 panic、为什么 panic、是否合理」
- 真正需要的是：每个 panic 都有对应测试覆盖，且 panic 场景文档清晰
不复杂但容易忽略。
