go test中可靠断言panic的方式是用defer+recover手动捕获，或使用testify/assert.panics（需传func()类型闭包），注意goroutine内panic无法被主goroutine recover捕获。
Go test里怎么断言函数真的panic了
Go标准库没有内置的 assert.Panics，别被第三方断言库名字带偏——真正可靠、无依赖的方式是用 testing.T 自带的 test.Panics（其实是 recover + 闭包捕获），或者更推荐的：用 test.Run 配合子测试隔离 panic，避免影响其他用例。
常见错误是直接调 funcThatPanic() 导致整个测试函数崩溃，测试提前退出，连失败提示都看不到。
- 必须把可能 panic 的代码包进匿名函数里，再传给
test.Panics或手动 recover - 不要在测试顶层直接调用会 panic 的函数
- 如果函数 panic 带 error 消息，得额外检查 panic 值是否匹配，
test.Panics只管“是否发生”，不校验内容
用 test.Panics 断言 panic（最简方式）
test.Panics 是 testing 包提供的工具函数，位于 testing/quick？错——它其实在 testing 包里，但**不是公开 API**。等等，别急：Go 1.22+ 确实没加；目前（Go 1.21）仍需自己写或用 testify/assert。所以实际最稳妥的是手写 recover 捕获逻辑，或引入轻量断言库。
如果你坚持零依赖：
立即学习“go语言免费学习笔记（深入）”；
- 定义一个闭包：
func() { riskyFunc() } - 用
defer+recover()捕获，并判断返回值是否非 nil - 注意：recover 只在 defer 中有效，且只对当前 goroutine 生效
示例：
func TestMyFunc_PanicsOnNilInput(t *testing.T) {
var panicked bool
defer func() {
if r := recover(); r != nil {
panicked = true
}
}()
myFunc(nil)
if !panicked {
t.Fatal("expected panic, but none occurred")
}
}
用 testify/assert.Panics 时为什么总报 “not a function call”
这个错误几乎全是参数类型搞错了：assert.Panics 第二个参数必须是 func() 类型，不是调用结果。比如写成 assert.Panics(t, riskyFunc())（带括号），Go 会先执行并 panic，测试根本进不到 assert 里。
- 正确写法：
assert.Panics(t, func() { riskyFunc() }) - 错误写法：
assert.Panics(t, riskyFunc())或assert.Panics(t, riskyFunc)（少括号但没传参，类型可能不匹配） - 如果
riskyFunc接收参数，闭包里要显式传入，比如func() { riskyFunc("bad") }
另外，testify/assert 的 Panics 不检查 panic 内容；要校验 panic error 字符串，得用 PanicsWithValue 或 PanicsWithError。
panic 测试里容易被忽略的 goroutine 和清理问题
如果被测函数内部启了 goroutine 并在其中 panic，主测试流程完全捕获不到——因为 recover 只作用于当前 goroutine。这种情况不会触发你写的 recover，也不会被 assert.Panics 捕获，测试会静默通过或超时失败。
- 凡是涉及 goroutine 的 panic 场景，必须同步等待（如用
sync.WaitGroup或chan），并在同一 goroutine 里做 recover - 如果函数有副作用（比如改了全局变量、开了文件），panic 后这些状态可能残留，影响后续子测试；建议每个测试用独立数据或加
defer清理 - 不要在 defer 里 recover 后继续执行业务逻辑——recover 只是让程序不崩，不代表状态可继续用
真正难测的从来不是“会不会 panic”，而是“在什么上下文、哪个 goroutine、带着什么残留状态 panic”。这些点不卡准，测试就只是自我安慰。
