Go测试中需用defer+recover捕获panic以验证预期行为：①在t.Run子测试中defer recover断言panic值；②用t.Run隔离风险避免干扰其他测试；③捕获意外panic添加诊断日志后t.Fatal。
在Go语言中，测试函数遇到panic会直接导致该测试用例失败。为了验证代码在特定条件下是否按预期抛出panic，或者确保意外的panic被正确处理，需要使用特殊的技巧来捕获和检查panic。
使用defer+recover捕获并验证预期panic
当你的目标是测试一个函数在非法输入或错误状态下是否会主动panic时（例如参数校验失败），应该在子测试中使用defer和recover来捕获这个panic，并断言其值符合预期。
- 利用t.Run创建一个子测试，将被测逻辑包裹在defer函数里调用recover。
- 如果recover返回了非nil值，说明发生了panic，接着检查这个值是否是你期望的错误信息或类型。
- 通过这种方式，你可以断言“这里必须发生panic”，从而使测试成功。
示例：测试一个除法函数在除数为0时是否panic。
func TestDivideByZeroPanic(t *testing.T) {
t.Run("should panic on divide by zero", func(t *testing.T) {
defer func() {
if r := recover(); r != nil {
// 验证panic的原因
expected := "division by zero"
if r != expected {
t.Errorf("expected panic message '%s', but got '%v'", expected, r)
}
} else {
t.Error("expected function to panic, but it did not")
}
}()
divide(10, 0) // 这个函数应在b==0时panic
})
}
隔离风险避免影响其他测试
单个测试中的panic默认只会影响当前的测试用例，得益于Go测试框架的设计。但显式地使用t.Run来隔离有panic风险的测试，是一种最佳实践。
立即学习“go语言免费学习笔记（深入）”；
- 即使没有使用recover，一个测试函数内部的panic也不会让整个测试包停止运行，后续的测试函数依然会被执行。
- 但对于同一个测试函数内的多个场景，使用t.Run可以确保一个场景的panic不会中断本函数内其他场景的测试。
- 这使得测试代码更加健壮和模块化，每个子测试独立运行、独立报告结果。
捕获意外panic以进行诊断
有时候你并不期望代码发生panic，但由于bug（如空指针解引用）导致了panic。虽然测试会自动失败并打印堆栈，但在某些复杂场景下，你可能想主动捕获它以便添加更多上下文日志。
- 可以在复杂的测试逻辑外围包裹一层defer+recover，用于在panic发生时记录当前的测试状态或输入数据。
- 捕获后通常会选择重新panic（panic(r)）或调用t.Fatal，以确保测试最终仍会失败，但附带了更丰富的诊断信息。
- 这种方法有助于快速定位由边界条件引发的隐蔽问题。
基本上就这些技巧，核心就是利用defer的特性在测试中安全地“尝试”可能崩溃的代码。
