Go单元测试中需用defer+recover捕获panic，不可用try/catch；推荐返回error而非panic；并发中goroutine的panic无法被主goroutine recover。
Go 单元测试中如何断言 panic 发生
Go 没有传统意义上的“异常抛出/捕获”机制，panic 是运行时崩溃信号，不能用 try/catch 捕获。要测试函数是否按预期 panic，必须用 recover 配合 defer 在子 goroutine 或封闭作用域中拦截。
常见错误是直接调用被测函数后写 if err != nil —— 这对 panic 完全无效，程序会直接终止。
- 必须在
defer中调用recover()，且该defer必须在 panic 触发前已注册 - 推荐将待测逻辑封装进匿名函数，再用
func() { ... }()调用，避免污染外部测试流程 - 不要在测试函数顶层 defer —— 它会在测试结束时才执行，起不到捕获作用
func TestDivideByZeroPanic(t *testing.T) {
defer func() {
if r := recover(); r == nil {
t.Fatal("expected panic but none occurred")
}
}()
divide(10, 0) // 假设这个函数内部 panic("division by zero")
}
使用 testify/assert 匹配 panic 内容
原生 testing 包只能判断 panic 是否发生，无法校验 panic 的值（比如字符串消息或自定义 error 类型）。此时需要手动解包 recover() 返回值，或借助 testify/assert 的 PanicsWithValue / PanicsWithError。
注意：testify/assert 的 panic 断言底层仍是基于 recover 封装，所以同样要求被测代码在当前 goroutine 中 panic。
-
PanicsWithValue(t, func() { f() }, "invalid input")：匹配 panic 值的==相等性（适用于字符串、int 等可比较类型） -
PanicsWithError(t, "EOF", func() { f() })：只匹配 panic 值的Error()方法返回字符串（适用于 error 类型） - 若 panic 的是自定义结构体且未实现
Error()，需用PanicsWithValue并确保该结构体可比较
import "github.com/stretchr/testify/assert"
func TestParseJSONPanic(t *testing.T) {
assert.PanicsWithValue(t, "invalid character", func() {
parseJSON([]byte("{ invalid }"))
})
}
测试 error 返回路径比 panic 更推荐
除非业务逻辑明确要求崩溃（如初始化失败、配置不可恢复错误），否则应优先让函数返回 error 而非触发 panic。这使得测试更直观、可控，也符合 Go 的惯用法（“don’t panic”）。
返回 error 的函数可直接用常规方式验证：
- 检查
err是否为nil - 用
errors.Is()判断是否为特定错误（如io.EOF） - 用
errors.As()提取自定义错误类型进行字段校验 - 避免用
err.Error() == "xxx"做字符串匹配 —— 易受格式变更影响
func TestOpenFileNotFound(t *testing.T) {
_, err := os.Open("/nonexistent/file.txt")
if !os.IsNotExist(err) {
t.Fatalf("expected file not found error, got %v", err)
}
}
并发场景下 panic 测试的陷阱
如果被测函数在 goroutine 中 panic（例如启动一个异步任务后内部 panic），主 goroutine 不会感知，测试会超时或直接通过 —— 因为 panic 发生在子 goroutine，而 recover 只能捕获当前 goroutine 的 panic。
这种情况下无法用常规方式断言，必须重构代码：要么把 panic 逻辑移到主流程，要么改用 channel + context 控制生命周期，并让错误通过 channel 返回。
- 绝对不要依赖 “goroutine 中 panic 后主线程能 recover” —— 这是常见误解
- 若必须保留 goroutine 内 panic，可在其内部加日志或发送信号到 channel，再由测试等待该信号
- 更稳妥的做法是：禁止业务代码在 goroutine 中 panic，统一转为
return err或向 channel 发送 error
