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 分支，那里往往藏着没被真正挑战过的逻辑。