Go test -count=1 怎么强制绕过测试缓存

如果你连续执行 go test ./...，第二次很快结束，而且摘要里出现 (cached)，通常不是测试被跳过了，而是 Go 在 package list mode 下复用了已经成功的测试结果。想让当前这次命令一定重新执行测试，最直接的写法是：

# 只让当前命令绕过测试结果缓存，不清理整个构建缓存
go test -count=1 ./...

官方地址：https://pkg.go.dev/cmd/go#hdr-Testing_flags

先从 (cached) 判断问题是不是测试缓存

这个问题最容易被误判成“测试没有运行”。Go 官方文档把 go test 分成不同调用形态；当命令带有包列表，例如 . 或 ./... 时，成功的包测试结果可以被缓存。命中后，Go 会重新展示之前的输出，并在摘要行用 (cached) 代替本次耗时。

缓存匹配并不是只看命令字符串。官方说明要求测试二进制相同，同时命令行参数只能来自一组可缓存测试参数，例如 -run、-short、-timeout、-parallel 和 -v。如果测试读取模块内文件或环境变量，这些输入也要保持不变，结果才可能继续匹配。

用 go test -count=1 强制当前命令重新执行

-count 的一般语义是让每个测试、基准测试和 fuzz seed 运行指定次数，默认值是 1。在排查缓存时，显式写出 -count=1 还有一个关键效果：它不属于可缓存测试参数，因此 Go 不会把这次 package list mode 的成功结果当作缓存命中来复用。

# 执行当前目录及其子包，并强制本次测试不复用结果缓存
go test -count=1 ./...

# 只重跑一个包；包路径放在命令中，便于缩小排查范围
go test -count=1 ./internal/order

这个开关只解决“是否复用测试结果”的问题。如果测试二进制需要重新编译，Go 仍然可能复用构建阶段的产物；这两类缓存服务不同。也就是说，-count=1 不承诺每个依赖包都从源文件重新编译，它保证的是测试执行不会直接拿上一次的成功测试结果冒充本次运行。

把 -count=1 和 -run 组合起来定位单个测试

如果整个仓库很大，不必一开始就重跑 ./...。可以先用 -run 缩小测试名称，再用 -count=1 排除结果缓存：

# 只执行名称匹配 TestCheckout 的测试，并绕过测试结果缓存
go test -count=1 -run '^TestCheckout$' ./internal/order

# 匹配一组以 TestCheckout 开头的测试，适合排查同一功能族
go test -count=1 -run '^TestCheckout' ./internal/order

这里有两个容易混淆的点。第一，-run 负责筛选测试，-count=1 负责避免复用结果，它们不是同一个开关。第二，命令行里不要把传给测试二进制的自定义参数误当成 go test 参数；如果确实要把剩余参数原样传给测试程序，应使用 -args，并把包列表放在它之前。

什么时候用 go clean -testcache

如果目标只是验证一次“改动后的测试是否真的重新执行”，优先用 -count=1，它影响范围最小。如果需要让后续普通 go test 也不再看到之前保存的测试结果，再考虑：

# 移除 Go 保存的测试结果缓存；不会等同于清空构建缓存
go clean -testcache

# 清理后按普通方式执行所有包测试
go test ./...

两者的区别可以这样记：go test -count=1 是一次运行级别的选择，适合现场排查；go clean -testcache 是对已有测试结果的清理，影响后续命令。不要为了验证一个测试就先清理全部缓存，也不要把 go clean -testcache 当成删除构建缓存的总开关。

没有 (cached) 仍然像没运行，继续查这三层

加上 -count=1 后，如果你仍然觉得测试没有按预期执行，可以按下面的顺序缩小范围：

1. 先看测试是否被筛选掉。检查 -run 的正则是否真的匹配目标函数；也要留意示例函数不会受 -count 重复执行规则影响。
2. 再看是不是只复用了构建产物。测试程序可能没有完整重编译，但这不代表测试结果被缓存；把“编译快”和“测试没跑”分开判断。
3. 最后打开缓存决策信息。在需要了解 Go 为什么复用或不复用测试结果时，可以临时使用 GODEBUG=gocachetest=1 获取缓存决策细节；它是诊断信息，不是替代 -count=1 的日常写法。

# 输出测试缓存决策细节，同时仍让当前命令明确绕过结果缓存
GODEBUG=gocachetest=1 go test -count=1 ./internal/order

最后的选择清单

所以，标题里的问题通常只需要一个答案：go test -count=1。先用它排除本次测试结果缓存，再根据 -run、构建产物和缓存决策信息继续定位，排查范围会比直接清空所有缓存更可控。

相关问题

• 为什么第二次 go test ./... 会显示 (cached)？因为成功的包测试结果满足缓存匹配条件，Go 直接复用了结果。
• -count=1 会不会让所有依赖都重新编译？不会。它针对测试结果缓存；构建缓存是另一层。
• 清理测试缓存应该用什么？使用 go clean -testcache，但先确认你需要的是全局清理，而不是单次绕过。

本文依据 Go 官方 cmd/go 测试文档整理，重点是测试缓存的使用边界，不延伸到测试顺序随机化。