go测试中panic不会自动捕获，必须用defer+recover显式处理：recover仅在defer函数内有效且仅捕获同goroutine的panic，常用于验证函数是否按预期panic并断言panic值。
Go 测试中 panic 不会自动被捕获，必须显式用 recover
Go 的 testing.T 运行时不会拦截 panic，一旦测试函数内发生 panic，测试立即失败并终止，defer 语句虽会执行，但若未配合 recover，无法阻止 panic 向上冒泡。这意味着：想验证某段代码是否 panic、或在 panic 后做清理/断言，必须手动构造 recover 逻辑。
常见错误是只写 defer func() { ... }() 却忘了调用 recover()，或者把 recover() 放在错误的作用域（比如没在 defer 内部调用）。
-
recover()只在defer函数中有效，且仅对当前 goroutine 的 panic 生效 - 必须在 panic 发生前注册 defer，否则来不及捕获
- recover 返回
Interface{}，通常需类型断言为Error或直接与预期 panic 值比较
用 defer + recover 捕获并断言 panic 内容
最典型场景：验证一个函数在非法输入下确实 panic，并检查 panic 的具体值（如 error message 或自定义 error 类型）。
注意：recover() 返回非 nil 表示发生了 panic；返回 nil 表示没 panic（或已被其他 recover 拦截）。
立即学习“go语言免费学习笔记（深入）”；
func TestDivideByZeroPanics(t *testing.T) { defer func() { if r := recover(); r == nil { t.Fatal("expected panic, but none occurred") } else if msg, ok := r.(String); !ok || msg != "division by zero" { t.Fatalf("unexpected panic: %v", r) } }() divide(10, 0) // 假设该函数内部 panic("division by zero") }- 务必在
defer内部调用recover()，不能提前赋值或延迟调用 - 类型断言要严谨：panic 可能是
string、error或自定义 Struct，需按实际 panic 类型匹配 - 如果被测函数可能不 panic，建议先设标志位或用
t.Helper()配合更清晰的失败提示
使用 test helper 函数封装 recover 逻辑
重复写 defer+recover 很冗余，尤其当多个测试需验证 panic 时。可封装成可复用的 helper，例如 mustPanic 或 expectPanic。
关键点在于：helper 必须接收函数值（func()），并在其内部触发 defer/recover，否则作用域不对，recover 无效。
func mustPanic(t *testing.T, f func()) { t.Helper() defer func() { if r := recover(); r == nil { t.Fatal("function did not panic as expected") } }() f() }使用方式：
func TestParseInvalidjsONPanics(t *testing.T) { mustPanic(t, func() { Parsejson(`{invalid`) // 假设该函数 panic }) }- helper 中的
defer和f()必须在同一函数体内，否则 recover 无法捕获f引发的 panic - 不要在 helper 外再套一层 goroutine（如
go f()），那会跨 goroutine，recover 失效 - 若需断言 panic 值，可扩展 helper 参数，例如加
expected interface{}并做比较
recover 对测试覆盖率和并发的影响
Go 的 recover 是运行时机制，不影响编译，但会影响测试行为和可观测性。
容易被忽略的是：在并行测试（t.Parallel()）中使用 recover 是安全的，因为每个测试在独立 goroutine 中运行，recover 只影响当前 goroutine。但若在主 goroutine 外启动额外 goroutine 并期望它 panic 被主测试 recover，那就不可能——recover 无法跨 goroutine 捕获。
- panic/recover 不会增加代码行覆盖率（
go test -cover），但 panic 分支本身应有对应测试 - 频繁 panic + recover 可能掩盖真实错误，尤其在 defer 中 recover 后继续执行，可能造成状态不一致
- 生产代码中应避免依赖 panic 做常规流程控制；测试中用 recover 是合理且必要的，但仅限于验证异常路径
实际写测试时，最容易漏掉的是 panic 类型判断和 defer 注册时机——前者导致误判（比如 panic 了但类型不符没报错），后者导致 recover 根本不触发。这两点比语法细节更常引发 flaky 测试。