FAIL后首行即定位线索：user_test.go:33: expected 5, got 6，直接跳转该行查断言上下文；空指针或panic表明异常路径未兜底；GoMock报错提示参数索引不匹配；-v必加看真实值；用t.Log而非log.Printf；优先require而非assert；偶发失败多因并发、状态污染或外部依赖；包名与go.mod需一致。
看懂 --- FAIL 后面那行定位线索
Go测试失败时，第一眼必须盯住 --- FAIL 紧接着的那行——它已经告诉你问题在哪个文件、哪一行、甚至哪个参数不匹配。这不是提示，是答案的起点。
- 典型输出：
user_test.go:33: expected 5, got 6→ 直接跳转到user_test.go第 33 行，检查if got != want的上下文 - 如果出现
nil pointer dereference或panic: runtime error: invalid memory address，说明被测函数在某个分支触发了空指针，不是断言错，是逻辑没兜住异常路径 - 遇到
Expected call at user_test.go:33 doesn't match the argument at index 1？这是 GoMock 报错，说明 mock 的第 2 个参数（索引从 0 开始）和EXPECT()设置的值对不上
用 go test -v 看真实变量值，别靠猜
不加 -v，你只看到“测试挂了”，加了才能看到 t.Log、中间状态、以及失败前最后一刻的 got 和 want 是什么。
-
t.Log("input:", a, "b:", b, "result:", result)必须配合-v才显示；而log.Printf会始终输出，容易干扰判断，一律改用t.Log - 第三方断言库如
testify/assert默认失败不中断，所有断言跑完才汇总错误——真正出问题的那行被淹没。改用testify/require，或至少加assert.Msg("xxx")让错误带上下文 - 原生写法最稳：
if got != want { t.Fatalf("expected %v, got %v", want, got) }，失败立刻停在调用处，堆栈干净，无依赖
并发、状态污染、外部依赖——三类“偶发失败”的真实原因
单独跑通过、合起来跑就失败？90% 是这三类问题之一，和代码逻辑无关。
- 先删掉
t.Parallel()再跑一次：如果不失败了，就是共享变量或全局状态没隔离，比如包级var cfg Config被多个测试改乱了 - 检查是否读写了真实文件、环境变量、数据库：用
t.TempDir()替代硬编码路径；os.Setenv后务必defer os.Unsetenv；数据库操作必须配tx, _ := db.Begin(); defer tx.Rollback() - 时间敏感逻辑（如
time.Now()）不能硬写死：注入一个clock func() time.Time类型的依赖，测试时传入固定时间戳，避免因系统时钟漂移导致随机失败
“undefined: XXX” 不是测试错，是构建模型理解错了
这个报错本质是 Go 编译器找不到符号，常见于测试文件和被测代码不在同一包，或模块未初始化。
- 确认两者
package声明一致：比如user.go是package user，那user_test.go也必须是package user，不能是main或空包 - 没
go.mod？执行go mod init your/project，否则go test ./...无法解析本地依赖 - 临时救急但不推荐：
go test -v ./user_test.go ./user.go显式指定所有依赖文件——这只适合调试，不能进 CI
最常被忽略的是：测试文件单独编译时，不会自动加载同目录下其他 .go 文件。你以为它“自然可见”，其实 Go 编译器根本没看见它。
