Go test 显示 cached 时怎么强制重新执行测试

执行 go test ./... 后看到 (cached)，通常说明 Go 复用了已经成功的包测试结果，并不是测试被跳过或失效。只想让当前测试重新执行，直接加 -count=1：go test -count=1 ./...。如果只是检查某个测试，可以再配合 -run 和 -v；只有需要让所有包的测试结果失效时，才使用 go clean -testcache。

看到 cached，先确认命令属于哪种模式

go test 不带包参数时，测试当前目录，属于 local directory mode，这种模式默认不使用测试缓存；写成 go test .、go test ./... 或指定包路径时，属于 package list mode，成功结果可能被复用。

因此下面三条命令的行为不能简单类比：

用 -count=1 强制指定范围重新执行

最推荐的处理方式是给原命令增加 -count=1，不要先删除整个构建缓存。它只改变这次测试的缓存策略，包范围、编译方式和测试代码仍由原命令决定。

# 只重跑当前模块下的所有包测试
go test -count=1 ./...

# 只重跑指定包，避免无关包增加等待时间
go test -count=1 ./internal/order

# 需要看到每个测试的输出时，同时打开详细日志
go test -count=1 -v ./internal/order

这里的关键不是把 GOCACHE 改到临时目录，而是明确告诉 go test 不要复用成功的测试结果。若只是验证一个刚修改的用例，这个范围通常比全量清缓存更稳。

用 -run 和 -v 复查某一个测试

如果全量重跑仍然太慢，可以把测试名称作为第二个筛选条件。-run 接受正则表达式，-v 让通过的测试也输出名称，二者和 -count=1 组合后更容易确认目标用例确实被执行。

# 只重跑名称中包含 Cache 的测试，并显示测试名
go test -count=1 -run '^Test.*Cache' -v ./...

# 只检查一个包的失败复现，避免把筛选参数传给测试函数
go test -count=1 -run '^TestRefreshCache$' -v ./internal/cache

正则没有匹配到测试时，命令可能很快结束，这不等同于缓存命中。排查时应同时确认包路径和测试函数名，必要时先用 go test -list . ./internal/cache 列出可匹配的测试。

什么时候需要 go clean -testcache

当你要让后续多次运行都重新判断测试结果，或者怀疑多个包的历史测试结果都不再适用，可以清理测试结果缓存：

# 只让成功的包测试结果失效，不删除编译产物
go clean -testcache

# 清理后再执行模块级测试
go test ./...

go clean -testcache 和 go clean -cache 不是一回事。前者针对测试结果，后者会删除整个构建缓存，通常会带来更多重新编译。除非是在处理构建缓存本身的问题，不要用后者替代测试缓存排查。

一张排查清单：从最小影响面开始

• 只看到 (cached)：先用 go test -count=1 原命令 重跑，不急着清缓存。
• 只关心一个用例：加 -run 和 -v，并用准确的包路径。
• 多个包都需要失效：使用 go clean -testcache，它不会删除模块下载内容。
• 结果仍与预期不符：检查测试是否读取包内文件、环境变量或外部服务；缓存判断会考虑部分输入是否变化，但它不能替你隔离外部副作用。

相关问题

加了 -v 还会显示 cached 吗？

可能会。-v 会改变输出详细程度，但不能代替 -count=1。需要确认测试二进制重新运行时，应把两者一起使用。

go clean -testcache 会删除 go.sum 或模块下载吗？

不会。它只让测试结果缓存失效，不删除模块文件；也不要把它和 -modcache 混用。

为什么我改了测试依赖的环境变量还看到 cached？

先用 -count=1 复现，再检查环境变量是否真的由测试进程读取，以及命令是否处于同一个包列表范围。缓存提示本身不是外部服务状态的证明。

记住一个顺序即可：单次确认用 -count=1，缩小范围用 -run，需要看过程加 -v，批量失效才用 go clean -testcache。