Go go test cache -count=1 和 -count=0 有什么区别

很多人第一次遇到 go test 输出 (cached) 时，会把 -count=1 和 -count=0 都当成“不要缓存”。它们确实都会让这次命令不再直接复用成功的测试结果，但后半段完全不同：-count=1 是绕过缓存后真实执行一次，-count=0 则把普通测试、基准和 fuzz seed 的执行次数设为零。

官方文档：https://pkg.go.dev/cmd/go

先判断 go test 是否处于可缓存的包列表模式

go test ./...、go test . 这类命令带有包参数，属于包列表模式。通过的包测试结果可以被 Go 命令缓存，下一次条件满足时会直接重放上一次输出，并把耗时位置显示为 (cached)。不带包参数、直接在当前目录执行的 go test 属于本地目录模式，缓存规则不同，不能只看到命令相似就推断行为一致。

这里的缓存保存的是成功的包测试结果，不是把测试源文件“冻结”起来。测试二进制、允许参与缓存的测试参数、包内文件和相关环境变量发生变化时，缓存匹配也会变化。因而“刚改了代码却看到 cached”通常要先确认实际执行的包路径和改动是否进入当前包，而不是马上把所有缓存目录删除。

Go test -count=1：绕过缓存并真正跑一次

-count 控制测试、基准和 fuzz seed 的运行次数，默认值是 1。官方给出的显式禁用测试缓存方式就是 -count=1。它做了两件事：让本次调用不直接采用成功测试结果缓存；让测试函数按一次执行。最常用的验证命令是：

# 强制绕过成功测试缓存，并实际执行所有匹配的测试一次
go test ./... -count=1

# 只排查某个测试时，保留 -run 选择器，再用 -count=1 防止旧结果干扰
go test ./path/to/pkg -run '^TestStore$' -count=1

所以它适合“我刚改完实现，想知道现在是否真的通过”“怀疑测试依赖时间、文件或环境变量”“想在 CI 中避免本机成功结果被误认为当前验证结果”等场景。它不会删除整个构建缓存，也不会替你清理业务代码写入的临时文件。

Go test -count=0：绕过缓存，但把运行次数设成零

-count=0 的关键字是“次数为零”，不是“把缓存计数清零”。普通测试和基准不会按一次运行；fuzz seed 也不执行。命令仍然需要解析包、准备测试二进制，因此它可以帮助你发现编译、包加载或测试构建阶段的问题，却不能证明测试函数本身通过。

Examples 是文档里的特殊情况：-count 不适用于 Examples，它们仍按规则执行一次。这个例外正是很多“命令成功但我以为所有测试都没跑”的误判来源。实战中不要用 -count=0 代替“跳过缓存后验证行为”；要验证行为，就换回 -count=1。

按排查目标选择命令

如果只是想确认缓存是否存在，先观察不带额外参数的命令是否出现 (cached)，再用 GODEBUG=gocachetest=1 获取解释。不要把 -count=0 当作缓存清理工具；缓存目录仍然可能保留，下一次普通命令也仍可能命中旧结果。

本地与 CI 的检查清单

1. 改动实现或测试后，先运行 go test ./... -count=1，确认测试逻辑真的走过。
2. 看到 (cached) 时，检查是否处于包列表模式，以及测试所读文件和环境变量是否改变。
3. 需要彻底让已有成功结果失效时，使用 go clean -testcache，不要期待 -count=0 完成清理。
4. 遇到“命令通过但测试日志没出现”，确认是否误用了 -count=0、-run 或其他选择器。
5. 把 CI 的验证命令和本地诊断命令分开记录：前者通常选择 -count=1，后者才可能短暂使用 -count=0 看构建边界。

常见问题

-count=1 会删除 Go 的构建缓存吗？

不会。它主要让本次成功测试结果不被直接复用；编译产物仍可能使用构建缓存。

-count=0 返回 PASS，能说明测试通过了吗？

不能。它可能只是完成了测试包的准备并没有运行普通测试；要确认测试行为，请使用 -count=1。

为什么 go test 和 go test ./... 的缓存表现不一样？

前者通常是当前目录的本地目录模式，后者明确给出包列表，属于包列表模式；Go 对成功包测试结果的缓存主要发生在后者这类调用中。