FAIL后首行即定位线索：user_test.go:33: expected 5, got 6，直接跳转该行查got/want；nil pointer或panic属逻辑未兜住异常；GoMock报错指mock参数不匹配；undefined:XXX多因包名或go.mod问题；-test.v必加才能见t.Log和真实值；断言须先求值再比较；复杂类型用reflect.DeepEqual；偶发失败优先排查并发、环境、依赖。
看懂--- 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()设置的值对不上 -
undefined: XXX不是测试错，是构建模型理解错了：常见于测试文件和被测代码不在同一包，或go.mod未初始化、包名不一致
加 -test.v 看真实值，别靠猜
go test -v 是排查断言失败最基础也最关键的开关。不加它，你只看到“测试挂了”；加了才能看到 t.Log、中间状态、以及失败前最后一刻的 got 和 want 是什么。
-
t.Log("input:", a, "b:", b, "result:", result)必须配合-test.v才显示；而log.Printf会始终输出，容易干扰判断，一律改用t.Log - CI 环境默认不带
-test.v，导致失败时无任何中间输出——建议在 CI 脚本中显式加上 - 子测试（
t.Run()）里用了t.Log()却没加-test.v，日志完全不可见
错误断言别写成一行，先求值再比较
常见错误是把待测函数和断言写在同一行，比如 assert.Equal(t, 42, riskyFunc()) —— 如果 riskyFunc() panic，assert 根本没机会执行，测试直接崩溃，还看不到断言失败的上下文。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法是先求值，再断言：
got := riskyFunc(); assert.Equal(t, 42, got) - 尤其对涉及 JSON 解析、数据库查询、HTTP 调用等易出错操作，必须拆开
- 若确实需要链式调用（如
json.Marshal().([]byte)），用defer func() { ... }()捕获 panic 并转为错误，再断言错误是否为 nil - 结构体、切片、map 等复杂类型比较，优先用
reflect.DeepEqual(got, want)，不用==；若用testify/assert，注意它对nilslice 和空 slice 判为相等，比reflect.DeepEqual更友好
偶发失败？先关并发、清环境、查依赖
单独跑通过、合起来跑就失败？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类型的依赖，测试时传入固定时间戳 - 快速验证是否是并发污染：
go test -test.cpu=1 -test.count=10连续跑 10 次，如果全通过，基本可锁定是并发问题
真正难缠的不是断言本身，而是那些在 -test.v 下才露头、在串行模式下消失、在 CI 里随机闪现的环境侧效应——它们不会出现在错误堆栈里，但总在你合上终端前悄悄改掉你的结果。
