Go test -count=1 和清理测试缓存有什么区别

看到 go test 输出里的 (cached)，通常不需要立刻删除整个缓存。-count=1 是给当前测试调用加的“不要复用测试结果”开关；go clean -testcache 则让 Go 构建缓存中的测试结果全部失效。前者影响一次命令，后者影响后续所有符合条件的测试，但两者都不会自动删除编译产生的构建缓存。

先分清：你要绕过的是哪一层缓存

Go 的缓存至少要按用途看。编译包和依赖会产生构建缓存，测试命令还可能保存“成功的包测试结果”。当测试二进制和可缓存参数仍然匹配时，go test 可以直接重放以前的结果，摘要行会出现 (cached)，测试进程并没有因为这次调用而重新执行。

因此，“清理测试缓存”不是“删除所有 Go 缓存”。go clean -cache 才是删除整个构建缓存；它的范围更大，下一次编译也要重新准备相关产物。排查一个怀疑受缓存影响的测试，先别把这两个动作混为一谈。

只检查当前代码时，用 go test -count=1

-count 是测试二进制的执行次数参数，-count=1 的特殊用途是显式禁用测试缓存。它不会要求你先清空本地缓存，也不会把测试跑两遍；它表达的是：这次指定的测试、基准或 fuzz seed 按一次执行，并且不要直接复用旧的成功测试结果。

最小排查命令如下：

# 只让本次模块测试绕过已有的测试结果缓存
go test -count=1 ./...

如果只关注一个包或一个测试，可以缩小范围：

# -run 只筛选目标测试，-count=1 负责本次不读测试结果缓存
go test -run '^TestConfig$' -count=1 ./internal/config

这里的关键是作用域：命令结束后，其他包的缓存仍在，构建缓存也仍在。下一次不带 -count=1 的普通调用，仍可能命中原有测试结果，前提是输入和可缓存条件没有变化。

需要整体失效时，用 go clean -testcache

当你希望本机所有包的成功测试结果都不再被直接复用，可以执行：

# 让构建缓存中的测试结果全部过期，但保留编译缓存
go clean -testcache

# 下一次普通测试会重新产出测试结果
go test ./...

这个命令适合测试环境变量、包内文件或外部依赖状态的排查，也适合清理一次性实验造成的测试结果干扰。它只处理测试结果缓存，不删除构建缓存，所以重新运行时通常仍可复用已经生成的编译产物。

可以把三种常见动作放在一起比较：

怎么确认这次测试到底有没有命中缓存

最直观的线索是摘要里的 (cached)。想看通过测试也输出测试日志，可以加 -v；想进一步看 Go 对测试缓存的判断，可以临时打开 gocachetest：

# -v 显示测试日志；gocachetest 输出缓存决策细节
env GODEBUG=gocachetest=1 go test -v ./internal/config

gocachetest=1 适合短时间定位问题，输出会比较多。它能帮助你确认是找到了旧结果、因为参数不满足缓存条件而跳过缓存，还是测试输入发生变化。不要把诊断日志当成测试断言本身，最终仍以测试命令的退出码和实际日志为准。

常见误区：为什么加了 -v 仍然不能代替 -count=1

-v 属于可缓存测试参数，单独加它并不等于明确关闭缓存；如果目标是保证当前调用重新执行，应直接写 -count=1。同理，修改了测试外部读取的文件或环境变量时，Go 会把这些输入纳入后续缓存匹配，但排查时最好用显式参数消除歧义。

只有在构建缓存本身异常，或系统上的 cgo 依赖库发生了 Go 工具无法自动识别的变化时，才考虑 go clean -cache 或用构建参数强制重建。普通的“测试好像没跑”问题，优先选择更窄的命令。

相关问题

为什么 go test 第二次会显示 (cached)？

在包列表模式下，前一次成功测试结果满足缓存条件，Go 就可以直接重放结果；用 -count=1 可显式禁止当前调用复用它。

go clean -testcache 会删除 go.sum 下载的依赖吗？

不会。它只让测试结果失效，不删除模块下载缓存；go clean -modcache 才是另一类更大范围的模块缓存操作。

改了测试代码还要手动清缓存吗？

通常不需要。Go 会根据源文件等输入重新判断缓存；若只是想验证这一次确实执行，用 go test -count=1 更直接。