Go测试失败应先看---FAIL后首行线索，如user_test.go:33: expected 5, got 6，直接定位文件行查断言上下文；遇panic或GoMock报错需分别检查空指针兜底与参数索引匹配；必加-test.v查看真实值，禁用log.Printf改用t.Log；偶发失败多因并发、状态污染或外部依赖未隔离。
Go 测试失败，第一反应不该是重跑或改断言，而是看 --- FAIL 后紧跟着的那行定位线索——它通常已告诉你问题在哪个文件、哪一行、甚至哪个参数不匹配。
看懂 --- FAIL 后的第一行输出
这是最直接的入口。Go 测试失败时，标准输出里 --- FAIL 下面那行就是关键线索：
-
user_test.go:33: expected 5, got 6→ 直接跳转到该行，检查断言上下文，重点看被测函数中循环边界、索引计算或初始值是否偏移 -
panic: runtime error: invalid memory address或nil pointer dereference→ 不是断言错，是函数某分支没做非空判断，应补if x == nil { t.Fatal("x is nil") }或用defer func() { recover() }()捕获并验证 panic 是否预期发生 -
Expected call at user_test.go:33 doesn't match the argument at index 1→ GoMock 报错，说明 mock 的第 2 个参数（索引从 0 开始）和EXPECT()设置的不一致，要核对类型、值、甚至是否用了指针 vs 值传递
加 -test.v 才能看到真实中间状态
不加这个 flag，t.Log() 输出会被吞掉，你只能看到“失败”，看不到“为什么失败”：
-
go test -test.run=TestFetchData -test.v是日常调试标配；CI 环境默认不带-test.v，导致日志全无，务必在 CI 配置中显式加上 - 别用
log.Printf替代t.Log：前者始终输出、干扰大；后者只在-test.v下可见，且自带测试上下文前缀 - 原生写法更稳：
if got != want { t.Fatalf("expected %v, got %v", want, got) }，失败立刻中断，堆栈干净，不依赖第三方断言库
排查并发与状态污染（偶发失败主因）
单独跑通过、合起来跑就失败？90% 是这三类问题之一，和业务逻辑无关：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先删掉所有
t.Parallel()再跑一次：如果不失败了，说明共享了未隔离的状态（比如包级var cfg Config、全局map、复用的 HTTP client） - 检查是否读写了真实外部依赖：如
http.Get、os.Open、sql.DB.Query—— 必须抽象为接口 + mock，数据库测试要用tx, _ := db.Begin(); defer tx.Rollback() - 时间敏感逻辑（如
time.Now()）不能硬写死：注入一个clock func() time.Time类型的依赖，测试时传入固定时间戳，避免系统时钟漂移导致随机失败
确认是不是在测「真实世界」
很多失败根本不是代码逻辑错，而是你在无意中测了不可控的外部环境：
- 运行
go test -race ./查数据竞争（注意位置：必须紧贴go test后、包路径前，go test ./ -race是无效的） - 用
dlv test -- -test.run=TestXxx调试：下断点在main.TestXxx（注意前缀是main.），单步、查变量、看 goroutine 状态；若用t.Parallel()，dlv 可能跳过断点，临时改用-test.cpu=1串行执行 -
undefined: XXX报错本质是编译器找不到符号：检查测试文件和被测代码是否同包、go.mod是否初始化、是否误把WriterMock{}当作io.Writer赋值（值接收器 vs 指针接收器陷阱）
真正难的不是定位单次失败，而是识别那些只在 CI、高负载或特定调度时机才暴露的问题——它们往往藏在并发状态、未清理的全局变量、或被忽略的接口实现细节里。
