Go test -count=1 如何排除测试缓存造成的假象

本地修改了测试依赖，重新执行 go test ./... 却瞬间通过，最容易误判为“问题已经消失”。先看摘要里有没有 (cached)：有它时，Go 可能只是重新展示之前缓存的成功结果，并没有再次启动测试二进制。排除这个假象最直接的命令是 go test -count=1 ./...。

把 -count=1 当成一次明确的现场复查：它禁用本次测试缓存复用，但不会替你修复测试、删除所有构建缓存，也不会自动把每个测试函数执行两遍。

先从输出判断是不是缓存结果

在 module 根目录运行：

# 先观察普通测试是否命中成功结果缓存
go test ./...

# 只跑一个包，便于把耗时和摘要对照起来
go test ./internal/order

如果输出类似下面这样，重点不是 PASS，而是末尾的 (cached)：

ok      example.com/shop/internal/order    (cached)

它说明 Go 找到了可以复用的成功测试结果。缓存命中时，之前的测试输出会被重新展示，耗时按近似零处理，所以“执行很快”不能证明测试真的重新访问了数据库、文件或外部服务。代码、module 内文件以及被测试读取的部分环境变量没有发生影响缓存匹配的变化时，都可能出现这种现象。

用 -count=1 做一次不复用缓存的复查

把原命令中的包范围保留，只加入 -count=1：

# -count=1 的目的，是让本次 go test 不复用成功测试缓存
go test -count=1 ./...

# 需要定位单个包时，保持同样的禁用缓存语义
go test -count=1 ./internal/order

这次通常能看到真实的编译和测试耗时。若你刚修改了测试夹具、环境变量或依赖，应该把这次结果与普通命令分开记录：普通命令显示 (cached)，只能说明缓存可用；带 -count=1 的结果才回答“当前代码重新跑一遍会怎样”。

不要把三个相近命令当成同一件事

排查时可以按下面的目标选命令：

多数“刚改完代码但输出没变”的场景，先用 -count=1 就够了。只有需要让后续所有普通测试都重新建立结果，或怀疑缓存目录本身有问题时，才考虑 go clean -testcache。如果要检查测试是否有不稳定副作用，才使用 -count=2 或更高次数。

把复查命令写进问题定位清单

在改动后遇到“测试还是旧结果”时，可以固定按这个顺序判断：

1. 先看输出是否有 (cached)，不要只看 PASS。
2. 用 go test -count=1 重跑，保留原来的 -run、-v 或构建参数。
3. 如果结果仍然异常，再检查测试是否读取了外部数据库、时间、随机数或未被缓存规则覆盖的环境状态。
4. 只有确认需要清空缓存时才执行 go clean -testcache，并记录清理动作。

CI 中也建议把“复现缓存”和“排除缓存”分成两条命令。普通流水线可以保留默认缓存以节省时间；遇到偶发通过、依赖升级或测试夹具修改时，用带 -count=1 的同包命令做诊断。这样能回答具体问题，而不是把每次构建都变成无缓存的慢测试。

常见问题

-count=1 会清空 Go 的全部构建缓存吗？

不会。它针对测试结果缓存的复用；编译缓存等其他缓存仍可能存在，不能把它当作全量清理命令。

看到 PASS 就能确定测试重新执行了吗？

不能。先检查摘要是否出现 (cached)，再用 -count=1 做对照。

为什么 -count=2 不是 -count=1 的加强版？

两者关注点不同：-count=1 常用于禁用缓存复查，-count=2 表示把测试运行两次，用来观察重复执行下的状态污染或不稳定。

记住一个实用判断：怀疑“刚才根本没跑”，先加 -count=1；怀疑“跑多次会不会不一致”，再考虑 -count=2；需要清理已有结果时，才使用 go clean -testcache。