Go测试中需用defer+recover在同goroutine捕获panic，testify/assert提供Panics/PanicsWithValue简化断言，Benchmark中不可测panic，goroutine内panic无法被主goroutine recover捕获。
Go测试中如何捕获并验证panic
Go的panic不能用try/catch捕获，测试时必须靠recover配合defer手动拦截。核心思路是：在测试函数内启动一个匿名函数并defer调用recover，再主动触发被测函数——这样panic不会终止整个测试进程。
- 必须在同一个goroutine里完成
defer recover()和触发panic，跨goroutine会失效 - 不要在被测函数内部recover——那属于业务逻辑，不是测试职责
- 若被测函数本身已含
recover，它可能吞掉panic，导致测试无法观测到预期崩溃
func TestDivideByZeroPanic(t *testing.T) {
defer func() {
if r := recover(); r == nil {
t.Fatal("expected panic, but none occurred")
} else if r != "division by zero" {
t.Fatalf("unexpected panic message: %v", r)
}
}()
Divide(10, 0) // 假设该函数直接panic("division by zero")
}
使用testify/assert包简化panic断言
原生Go测试写recover样板多、易出错。用testify/assert的Panics或PanicsWithValue可一行完成断言，底层仍是封装了recover逻辑。
-
Panics只检查是否发生panic，不关心内容 -
PanicsWithValue严格比对panic值（支持string或error） - 注意：这些函数返回
bool，需配合assert.True(t, ...)或直接用require.Panics（失败立即终止）
import "github.com/stretchr/testify/assert"
func TestParseJSONPanic(t *testing.T) {
assert.Panics(t, func() { ParseJSON(`{invalid`) })
assert.PanicsWithValue(t, t, "invalid character", func() { ParseJSON(`{invalid`) })
}
避免在Benchmark中测试panic
go test -bench运行的是Benchmark*函数，它们**不支持recover**——一旦panic，整个基准测试直接退出，且不会报错，只会静默终止或显示panic: ... (BENCH)后中断。
- panic测试只能放在
Test*函数里，绝不能混进Benchmark* - 如果想测“带错误处理的健壮版本”的性能，应构造合法输入+显式错误返回路径，而非依赖panic分支
- 某些CI环境对benchmark panic更敏感，可能被当作构建失败
panic测试容易漏掉的边界：goroutine与defer执行顺序
当被测函数启动新goroutine并在其中panic，主goroutine的defer recover()完全捕获不到——这是最常被忽略的坑。
- 例如：
go func() { panic("in goroutine") }()→ 主测试函数不会panic，recover返回nil - 解决方式只有两种：改被测逻辑（让panic发生在主goroutine），或用
sync.WaitGroup+共享变量记录panic状态（不推荐，复杂且竞态难测） - 更务实的做法：把goroutine内panic转为向channel发送error，测试端从channel收error并断言
真正难测的不是panic本身，而是它发生的上下文——goroutine、defer链、嵌套调用层级。写panic测试前，先确认panic一定出现在你控制的栈帧里。
