Go测试需覆盖异常场景，必须用errors.Is/As断言具体错误类型，为每个公开错误变量和校验函数补失败路径测试，主动构造panic、nil输入等边界条件，并在表驱测试中显式声明expectError字段。
只测 nil 不等于覆盖异常场景
很多 Go 测试只验证了正常返回和 nil 错误，但没真正触发、捕获、断言具体的错误类型。比如函数返回 errors.New("timeout")，测试却只写 if err != nil { t.Fatal() } —— 这根本没验证“是不是 timeout”，只是在检查“有没有错”。覆盖率工具会显示这行执行了，但逻辑漏洞照旧。
- 必须用
errors.Is(err, targetErr)或errors.As(err, &target)做类型/语义断言，而非仅判空 - 每个公开错误变量（如
ErrInvalidInput）都应有对应测试用例显式触发并验证 - 避免在测试中用
fmt.Sprintf("%v", err)比对字符串——它脆弱且绕过错误封装语义
checks.ErrorIs 类辅助函数必须补失败路径测试
像 internal/test/checks/checks.go 中的 ErrorIs 函数，本身含 t.Fatal() 分支，但若所有测试只传入匹配的 err，那这个关键失败分支就永远不执行——导致该函数自身覆盖率虚高，且掩盖了真实错误传播是否可靠。
- 为每个校验型辅助函数单独写失败用例：例如调用
ErrorIs(t, io.EOF, os.ErrNotExist, "should be ErrNotExist") - 用
t.Log(err)在失败测试里输出实际错误值，便于快速定位是上游构造错了，还是判断逻辑有误 - 这类函数一旦被广泛复用，其自身缺陷会扩散到整个测试套件，优先保障其健壮性比业务逻辑还重要
边界输入要主动“造错”，不能等 panic
Go 的异常场景不全是 error 返回值；还有 panic（如切片越界、nil 指针解引用）、死循环、竞态。这些不会被 go test -cover 统计到，但线上一碰就崩。
- 对接受 slice/map/chan 的函数，必须测
nil输入：如f(nil)是否 panic？是否返回明确 error？ - 对带
context.Context的函数，用context.WithCancel+ 立即cancel()触发ctx.Err()路径 - 用
go test -race运行并发测试，尤其当函数内部有共享状态或未加锁 map 操作时
func TestProcessData_WithNilSlice(t *testing.T) {
// 主动传入 nil，不是忽略它
err := ProcessData(nil)
if !errors.Is(err, ErrEmptyInput) {
t.Fatalf("expected %v, got %v", ErrEmptyInput, err)
}
}
表驱测试（Table-Driven）必须包含 error 字段
表驱测试常被用来覆盖多个输入组合，但多数人只列 input 和 expected，漏掉 expectError 字段，结果异常路径全靠运气覆盖。
- 每个测试用例结构体里加
expectError bool或更细粒度的expectErrorIs error - 执行后统一判断：
if tt.expectError && err == nil { t.Fatal("expected error but got nil") } - 避免把 error 断言逻辑散落在每个 case 里——易遗漏、难维护
最常被忽略的是：**异常场景的测试代码本身，也要被测试覆盖**。比如你写了 10 个 error 判断，但验证这些判断的测试函数里，只跑了成功分支——那整套异常防御就是纸糊的。动手前先看一眼 go tool cover -html=coverage.out 里红色高亮的 if err != nil 分支，那里往往藏着没被真正挑战过的逻辑。
