17370845950

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，这些副作用依然存在。

• 测试中 recover ≠ 生产环境容错 —— 生产代码该加 error 返回就加，不该依赖 panic
• 并发测试中，多个 goroutine 同时 panic 时，recover 只能捕获本 goroutine 的，其他仍会终止测试进程
• 如果被测函数本身包含 defer+recover，测试时反而可能收不到 panic —— 此时应测它 recover 后返回的 error

真正难的不是写 recover，而是判断：这里到底该 panic 还是该返回 error？这个问题在测试里暴露得最清楚。