Go 测试中 panic 不会自动 recover，需手动用 defer+recover 捕获并断言；testify 的 assert.Panics 等可简化该流程，但 recover 仅验证行为而非修复错误，且不跨 goroutine 生效。
Go 测试中 panic 不会自动被 recover，必须手动处理
Go 的 testing.T 运行时默认不拦截 panic，一旦测试函数或被测代码触发 panic，整个测试用例立即终止并报错（如 panic: ……），无法继续验证错误恢复逻辑。这不是 bug，而是设计使然：Go 要求你显式控制异常路径，不能依赖隐式捕获。
在 test 函数里用 defer + recover 捕获 panic
想验证某段代码是否按预期 panic（比如参数校验失败），需在测试函数内启动一个匿名函数并用 defer + recover 拦截。注意：recover 只对当前 goroutine 有效，且必须在 panic 发生前已注册 defer。
-
recover()必须在 defer 中调用，写在普通语句位置无效 - 不能在被测函数内部 recover —— 那属于业务逻辑，不是测试职责
- 捕获后建议用
t.Errorf或require.Nil(t, ……)显式断言结果
func TestDivideByZeroPanics(t *testing.T) {defer func() {if r := recover(); r == nil {t.Fatal("expected panic but none occurred") } if r != "division by zero" {t.Fatalf("expected'division by zero', got %v", r) } }() Divide(10, 0) // 假设该函数直接 panic("division by zero") }使用 testify/assert 或 require 简化 panic 断言
手写 defer/recover 模板重复、易出错。testify 的 assert.Panics 和 require.Panics 封装了这套逻辑，更简洁可靠。
-
assert.Panics(t, func(){……})：仅断言 panic 是否发生，不关心 panic 值 -
assert.PanicsWithValue(t, "expected msg", func(){……})：同时校验 panic 的具体值 -
require.Panics在失败时直接终止当前测试，适合前置条件检查
func TestParseJSONPanicsOnInvalid(t *testing.T) {assert.PanicsWithValue(t, "invalid JSON", func() {ParseJSON([]byte("{ invalid")) // 假设此函数 panic }) }recover 在测试中不等于“修复错误”，只是验证行为
有人误以为在测试里 recover 就能让被测函数“安全运行”，其实不然。recover 只影响当前测试函数的执行流，对被测函数内部状态无任何修复作用。若函数 panic 前已修改全局变量、写入文件或启动 goroutine，这些副作用依然存在。
立即学习 “go 语言免费学习笔记（深入）”；
- 测试中 recover ≠ 生产环境容错 —— 生产代码该加 error 返回就加，不该依赖 panic
- 并发测试中，多个 goroutine 同时 panic 时，recover 只能捕获本 goroutine 的，其他仍会终止测试进程
- 如果被测函数本身包含 defer+recover，测试时反而可能收不到 panic —— 此时应测它 recover 后返回的 error
真正难的不是写 recover，而是判断：这里到底该 panic 还是该返回 error？这个问题在测试里暴露得最清楚。
