-go test -count=1 是唯一能彻底禁用测试缓存、强制重跑的方式，它跳过所有缓存判断逻辑，不复用二进制和结果；而 -v、-run、go clean -testcache 或清理 GOCACHE 均无法完全规避缓存。
go test -count=1 是唯一可靠方式
CI 或本地调试时，go test 默认会缓存上一次成功测试的结果，导致修改代码后仍显示 PASS，掩盖真实问题。这不是“跳过”，而是 Go 测试运行器主动复用上次编译产物和结果。唯一能彻底绕过缓存、强制重跑的参数是 -count=1 —— 它让测试运行器每次都将测试视为全新执行，不查缓存、不复用二进制、不跳过任何步骤。
常见误操作包括：
- 只加
-v或-run：完全不影响缓存逻辑 - 用
go clean -testcache：只能清掉历史缓存，但下次运行仍可能命中新缓存（尤其未配-count=1时） - 删
$GOCACHE下的测试相关目录：徒劳，go test的测试缓存独立于GOCACHE编译缓存，且路径不公开暴露
为什么 -count=1 比 go clean -testcache 更有效
go clean -testcache 只清除已落盘的测试结果快照，但 go test 在执行中还会基于源码哈希、依赖版本、构建标签等动态判断是否可复用——这些判断在未加 -count=1 时依然生效。而 -count=1 直接关闭整个缓存决策链路，连哈希比对都跳过。
实操建议：
- CI 流水线中必须固定使用
go test -count=1 ./...，不能省略 - 本地调试怀疑缓存干扰时，直接运行
go test -count=1 -v ./service/user，别先clean - 搭配
-race或-timeout使用时，-count=1必须放在最前面或至少不被覆盖（Go 参数顺序无严格要求，但习惯上放左）
注意 -count 不是并发控制参数
新手常混淆 -count 和 -parallel：-parallel 控制测试函数内子测试的并发数，-count 控制整个测试包的执行轮次。设 -count=2 会跑两遍全部测试（含 setup/teardown），不是“跑得更快”，反而更慢；设 -count=1 才是“只跑一遍且不缓存”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
典型错误写法：
-
go test -parallel 4：完全不关缓存，只是让t.Parallel()的测试并行跑 -
go test -count=3：重复执行三次，浪费时间，且中间两次仍可能被缓存优化掉（取决于 Go 版本） -
go test -count=1 -race正确；go test -race -count=1也正确——顺序不影响语义
验证缓存是否真被禁用
最直接的方式是改一行测试里的 t.Error("xxx") 为 t.Fatal("yyy")，然后不加 -count=1 运行，观察是否仍报旧错误；加上后必须立刻报新错误。另一个信号是看终端输出里是否出现 cached test results 字样——加了 -count=1 就不会出现。
补充一点容易被忽略的细节：如果测试里用了 os.Setenv 或临时文件，仅靠 -count=1 不足以保证隔离性——它只管缓存，不管副作用。这类测试还需配合 t.Cleanup 或显式重置状态，否则即使禁用缓存，也可能因环境残留导致 flaky 行为。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
