应使用 assert.PanicsWithValue 或 assert.PanicsWithError 校验 panic 值或错误类型，避免仅用 assert.Panics；传函数时必须用 func() { fn() } 而非 fn()，否则 panic 提前触发导致测试失败。
Go test 里怎么断言函数真的 panic 了
用 testify/assert 的 assert.Panics 最直接，但它只检查是否 panic，不校验 panic 的值或类型——很多测试看似通过，其实没测到关键逻辑。
常见错误现象：assert.Panics(t, func() { panic("wrong msg") }) 对任意 panic 都返回 true，哪怕你期望的是 panic(&MyError{}) 却收到字符串 panic，测试照样绿。
- 必须配合
assert.PanicsWithValue或assert.PanicsWithError校验 panic 内容 - 如果 panic 是自定义 error 类型，优先用
assert.PanicsWithError（它调用Error()方法比对） - 若 panic 是原始字符串或非 error 值（比如
panic(42)），只能用assert.PanicsWithValue
不用 testify，纯标准库怎么测 panic
标准库没有内置 panic 断言，得靠 recover + 匿名函数手动捕获——写法略啰嗦，但无第三方依赖，适合轻量或 CI 环境受限场景。
使用场景：项目禁用外部 test 工具、想明确控制 panic 捕获时机、或调试 recover 行为本身。
立即学习“go语言免费学习笔记（深入）”；
- 必须在 goroutine 内调用被测函数，否则 panic 会终止整个 test
-
recover()只在 defer 中有效，且仅对当前 goroutine 的 panic 生效 - 别漏掉
if r := recover(); r != nil { ... }后的类型断言，否则无法比对 panic 值
示例：
func TestFooPanics(t *testing.T) {
var panicked interface{}
func() {
defer func() { panicked = recover() }()
foo() // 被测函数
}()
if panicked == nil {
t.Fatal("expected panic, but none occurred")
}
if msg, ok := panicked.(string); !ok || msg != "expected" {
t.Fatalf("unexpected panic: %+v", panicked)
}
}
assert.Panics 为什么有时不报错却实际没触发
根本原因：传给 assert.Panics 的是函数值，不是调用结果。如果写成 assert.Panics(t, fn())（带括号），就变成先执行再传返回值，panic 在断言前就炸了，test 直接失败，根本走不到 assert 逻辑。
性能影响：这种写法还会导致被测函数在测试 setup 阶段就被执行，可能污染状态或触发副作用。
- 永远传函数字面量：
assert.Panics(t, func() { fn() }) - 不要提前调用：
assert.Panics(t, fn())❌ - 也不要用变量存函数再调：
f := fn; assert.Panics(t, f())❌
panic 类型不匹配导致测试误判的典型坑
Go 里 panic(nil)、panic("msg")、panic(errors.New("x"))、panic(&MyErr{}) 全是不同底层类型，assert.PanicsWithError 只对实现了 error 接口的值有效，其他一概返回 false。
容易踩的坑：把 panic(fmt.Errorf(...)) 和 panic("string") 混用，却统一用 assert.PanicsWithError 断言，后者永远失败。
- 查清被测函数实际 panic 的类型：加一行
log.Printf("panic type: %T, value: %+v", r, r)在 recover 里 - 字符串 panic → 用
assert.PanicsWithValue - error 类型 panic → 用
assert.PanicsWithError，且确保 error 实现了Error()方法 - 结构体指针 panic → 除非它实现了
Error()，否则只能用assert.Panics或WithValue做深度比对
