t.Fatal立即终止测试函数并标记失败，t.Error仅标记失败但继续执行；前者用于前置条件不满足等不可恢复错误，后者适用于需收集多个错误的场景。
t.Fatal 和 t.Error 的核心区别：是否中断执行
根本区别就一条：t.Fatal 一调用就立刻退出当前测试函数，t.Error 只标记失败但继续跑完剩余代码。这不是“语气轻重”问题，而是控制流是否被截断的实质性差异。
什么时候必须用 t.Fatal？前置条件不满足时
当后续断言或逻辑严重依赖某个前提（比如初始化失败、配置缺失、mock 未 setup），再往下跑毫无意义甚至会 panic，就必须用 t.Fatal 或 t.Fatalf。
- 常见错误现象：测试因 nil pointer panic 报错，但真实原因是前面
db.Connect()失败后没终止，却继续调用了db.Query() - 正确做法：检查 setup 步骤，失败立即
t.Fatalf("failed to init db: %v", err) - 不要用
t.Error替代——它不会阻止后续代码执行，可能掩盖真正的问题源头
什么时候该用 t.Error？需要收集多个失败点
当你希望一次运行暴露出所有不一致项（比如批量校验字段、对比结构体多个字段），而不是只看到第一个就停住，就该用 t.Error 或 t.Errorf。
- 典型场景：表格驱动测试中，对一组输入逐一验证，想看到全部失败项而非只第一个
- 参数差异：
t.Errorf("field X mismatch: got %v, want %v", got.X, want.X)比t.Fatal更利于调试定位 - 注意：这些日志默认不输出，需加
-v参数才能看到；而t.Fatal的消息总会显示
别踩的坑：混用日志与断言、忽略 Helper 语义
t.Log 和 t.Error 看似都是输出，但行为完全不同：前者只是记录，后者会翻红并影响测试结果；且它们都只在当前测试函数内有效，子测试里要显式传 t。
立即学习“go语言免费学习笔记（深入）”；
- 绝对避免：
fmt.Println或log.Printf—— 它们逃逸出 testing 框架，无法被go test -v统一管理，还会污染标准输出 - 子测试中误用：在
t.Run("case1", func(t *testing.T) { ... })内部，必须用传入的t，不能闭包引用外层t - 调试时建议加
t.Helper()：让错误行号指向真正调用处，而不是框架内部，尤其在封装断言函数时
func TestDivide(t *testing.T) {
t.Helper()
tests := []struct{
a, b int
want int
wantErr bool
}{
{10, 2, 5, false},
{10, 0, 0, true},
}
for _, tt := range tests {
t.Run(fmt.Sprintf("divide(%d,%d)", tt.a, tt.b), func(t *testing.T) {
t.Helper()
got, err := divide(tt.a, tt.b)
if tt.wantErr {
if err == nil {
t.Fatal("expected error but got nil") // 前置条件失败，必须终止
}
return
}
if err != nil {
t.Errorf("unexpected error: %v", err) // 允许继续检查 got 值
return
}
if got != tt.want {
t.Errorf("got %v, want %v", got, tt.want) // 收集多个错误
}
})
}
}
关键不是记哪个“更严重”，而是看你要不要让测试继续往下走——这直接决定你能看到多少线索，也决定 CI 上失败报告是否可读。 
