用 testify/assert.panics 断言 panic 最省事，但仅捕获顶层 panic；原生方式需 defer+recover 手动捕获以校验 panic 值；panicswithvalue 仅支持 string 或 error 类型 panic；goroutine 内 panic 无法被 panics 捕获，因跨协程崩溃测试进程。
Go 测试里怎么断言函数真的 panic 了
直接用 testify/assert.Panics 最省事，但得注意它只捕获顶层 panic，不抓 recover 后的“假 panic”或嵌套 goroutine 里的 panic。
常见错误是写了 assert.Panics(t, func() { ... })，结果测试通过了，但函数其实根本没 panic——比如你忘了加 panic("xxx")，或者 panic 被内部 recover() 吃掉了。这时候 assert.Panics 会误判为“成功捕获”，实际只是什么都没发生。
- 必须传一个无参函数（
func()类型），不能直接调函数，否则 panic 会直接崩掉整个测试 - 如果被测函数带参数，用闭包包装：
func() { fn("arg1", 42) } - 别在闭包里做 recover —— 这会让
assert.Panics看不到原始 panic
不用 testify 时，原生 Go 怎么测 panic
靠 recover() + defer 手动捕获最可靠，尤其适合验证 panic 内容或排除干扰。
典型场景：你要确认 panic 的 error message 是 "index out of range"，而不是随便一个 panic 就算数。这时 assert.Panics 不够用，必须自己接住并检查 recover() 返回值。
立即学习“go语言免费学习笔记（深入）”；
- 必须在 defer 里调
recover()，且 defer 要紧挨着被测函数调用之前 -
recover()返回nil表示没 panic；返回非nil值才是 panic 对象（通常是string或error） - 别在测试函数里写多个 defer —— 顺序容易错，panic 可能被错误的 defer 捕获
示例：
func TestFooPanicsWithMessage(t *testing.T) {
var panicked interface{}
defer func() { panicked = recover() }()
foo() // 这里 panic
if panicked == nil {
t.Fatal("expected panic, but nothing happened")
}
if msg, ok := panicked.(string); !ok || msg != "bad input" {
t.Fatalf("unexpected panic: %+v", panicked)
}
}
assert.Panics 和 assert.PanicsWithValue 区别在哪
assert.Panics 只管“有没有 panic”，assert.PanicsWithValue 多一步：比对 panic 的具体值（比如 panic("oops") 中的 "oops"）。
但要注意：Go 里 panic 可以是任意类型，而 assert.PanicsWithValue 默认只接受 string 或实现了 Error() 方法的类型。如果你 panic 了一个 struct 或 int，它会直接失败，不是因为值不对，而是类型不匹配。
- panic 字符串时用
assert.PanicsWithValue(t, "oops", func() { ... }) - panic 自定义 error 时，确保它有
Error() string方法，否则用assert.Panics+ 手动recover更稳 - 不要指望
assert.PanicsWithValue能 deep-equal struct panic —— 它只调Error()或fmt.Sprintf("%v", v)
goroutine 里的 panic 为什么 assert.Panics 捕不到
因为 assert.Panics 依赖当前 goroutine 的 panic/recover 机制，而新起的 goroutine panic 会直接终止那个 goroutine，并触发 Test 函数所在主 goroutine 的未捕获 panic —— 此时测试进程已崩溃，断言根本没机会执行。
典型错误写法：go fn() 然后跟 assert.Panics，这几乎一定失败。不是断言失效，是测试直接挂了。
- 要测 goroutine panic，必须用
sync.WaitGroup+recover在 goroutine 内部捕获 - 或者改用
runtime.Goexit()模拟退出（但不是 panic），再配合 channel 通知主 goroutine - 更务实的做法：避免在测试中启动 goroutine 做关键逻辑；把可能 panic 的逻辑抽成同步函数，先单独测它
事情说清了就结束
