Go测试失败应先看首条错误行，配合-v参数、避免defer中t.Log、慎用全局变量、-race检测竞态、t.Logf替代t.Log、-count=1防状态干扰、-failfast止损，日志是调试核心。
Go测试失败时如何快速定位问题根源
测试失败后第一反应不应该是重跑，而是看go test输出里最靠前的错误行——它通常指向真正出错的断言或panic位置。但很多情况下错误堆栈被截断、日志被吞掉，或者失败发生在并发goroutine里，导致主测试函数没报错却返回fail。关键要打开详细输出并控制日志流向。
- 始终加
-v参数：让每个测试用例的t.Log()和t.Error()都可见，否则默认只输出失败摘要 - 避免在
defer里调用t.Log()：如果测试提前失败，defer可能没执行，关键日志就丢了 - 并发测试中慎用全局变量或共享状态：失败可能由非当前goroutine触发，堆栈不反映真实源头
- 对疑似竞态问题，立即加
-race运行：它能暴露隐藏的读写冲突，比手动加锁排查快得多
为什么t.Log()在失败时不显示，以及怎么让它必现
t.Log()输出默认只在-v模式下打印，且仅当测试通过时才完整输出；一旦失败，Go会截断日志，只保留最后几行。这不是bug，是设计取舍——但对调试极不友好。
- 改用
t.Logf("debug: %+v", x)配合-v，确保结构体字段可读 - 在关键分支前强制刷新：
fmt.Fprintln(os.Stderr, "hit branch A")——stderr不受t.Log()生命周期限制 - 若用
testify/assert等库，注意其assert.Equal()失败时不会自动打印期望/实际值，需手动加t.Logf()辅助 - 自定义测试辅助函数时，别把
*testing.T传进goroutine：它不是线程安全的，多goroutine写t.Log()可能丢日志或panic
go test -run=TestName -v -count=1各参数的实际作用
组合参数不是随便加的，每个都在影响失败复现的确定性。比如-count=1看似多余，实则防止因缓存或状态残留导致“有时过有时不过”。
-
-run支持正则：-run=^TestUser.*Create$精准匹配，避免无关测试干扰输出 -
-v开启详细模式，但会抑制颜色输出（某些CI环境需要显式加--no-color才能兼容） -
-count=N重复运行N次，用于检测随机性失败；但N>1时，t.Log()只在最后一次失败时全量输出，前面的会被覆盖 -
-failfast值得常开：遇到第一个失败就停，避免后续测试因前置状态损坏而报出误导性错误
常见错误信息含义与对应检查点
Go测试报错文本短，但每种都有明确指向。例如test timed out after 10s不是代码慢，而是测试卡死在某个阻塞调用上。
立即学习“go语言免费学习笔记（深入）”；
-
panic: test timed out→ 检查是否有未关闭的time.AfterFunc、无缓冲channel写入、或http.Get没设timeout -
expected ..., got ...→ 多半是浮点比较用==而非cmp.Equal()或assert.InDelta()，注意精度误差 -
cannot find package出现在测试中 → 很可能是_test.go文件放在了子目录但没加//go:build test构建约束 -
fatal error: all goroutines are asleep→ 主goroutine已退出，但其他goroutine还在等channel或waitgroup，典型死锁
真正难定位的从来不是语法错，而是那些不报panic、不超时、只是逻辑结果不对的case——它们依赖你提前埋好t.Log()和输入/输出快照。日志不是补丁，是测试代码不可分割的一部分。
