go test 缓存导致旧结果如何强制重跑

如果第二次执行 go test ./... 很快结束，并在摘要里看到 (cached)，通常不是测试被跳过，而是 Go 复用了上一次成功的包测试结果。想让当前命令真正再跑一次，最直接的写法是：

# -count=1 只改变这次测试命令的执行策略，不需要先清空整个构建缓存。
go test -count=1 ./...

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

先记住三个判断：看到 (cached) 才说明命中了可复用的成功结果；-count=1 是强制当前命令重跑的惯用开关；如果想知道 Go 为什么命中或放弃缓存，可以临时使用 GODEBUG=gocachetest=1 输出决策信息。

先确认看到的是缓存结果而不是测试没被发现

Go 在 package list mode 下会缓存成功的包测试结果。命中后，Go 会重新显示之前的测试输出，并在摘要位置显示 (cached)，而不是再次启动测试二进制。这个现象和“包里没有 _test.go 文件”或“-run 没有匹配到测试”不是一回事。

可以先用普通命令观察摘要，再用显式测试名称确认入口是否存在：

# 先观察包级摘要；如果命中缓存，摘要通常会出现 (cached)。
go test ./...

# 只列出测试函数，确认测试入口确实被 Go 发现。
go test -list '^Test'

# 让一次运行不使用旧的成功结果，便于与上一次摘要对照。
go test -count=1 -v ./...

如果普通命令没有显示 (cached)，不要先下结论说缓存失效。可能是第一次运行、测试失败没有可复用的成功结果，也可能是命令包含了不能参与缓存匹配的参数。先看完整摘要，再决定是否需要强制重跑。

用 go test -count=1 强制当前命令重跑

-count 控制测试运行次数。把它设为 1 时，Go 官方文档把它作为显式禁用测试缓存的惯用方式。它针对当前这条 go test 命令，不等于删除 GOCACHE 中的所有编译产物，所以通常比先执行全局清理更适合排查“我想现在再跑一次”的问题。

# 只重跑当前包，适合先缩小问题范围。
go test -count=1 ./internal/order

# 强制所有包重新执行测试，并保留详细输出。
go test -count=1 -v ./...

# 只重跑匹配的测试函数；-run 负责筛选，-count=1 负责绕过结果缓存。
go test -count=1 -run '^TestOrderTotal$' ./internal/order

这里不要把 -count=1 和“清理所有缓存”混为一谈。前者是本次测试的行为控制，后者会影响后续命令的构建与测试成本。除非正在处理缓存目录损坏或需要重置本地环境，否则先用前者验证测试是否真的会失败或通过。

用一个最小测试项目复现缓存差异

为了理解输出，可以准备一个很小的包：第一次运行成功，第二次使用相同的可缓存参数，Go 可能复用结果；第三次加上 -count=1，则要求当前命令重新执行测试函数。

package cachecheck

import "testing"

func TestStableValue(t *testing.T) {
    // 用固定断言演示成功结果缓存；不要把时间或随机数混入这个最小例子。
    want, got := 2+3, 5
    if got != want {
        t.Fatalf("want %d, got %d", want, got)
    }
}

# 第一次运行会真正执行测试函数。
go test -v ./...

# 相同输入再次运行时，成功包结果可能显示为 (cached)。
go test -v ./...

# 这次明确要求重新执行测试函数。
go test -count=1 -v ./...

这个例子只用来观察机制，不应把“第二次一定显示 cached”当成跨环境的硬编码输出。缓存匹配还会考虑测试二进制以及命令行参数；工作区源码、测试读取的包内文件和相关环境变量发生变化时，Go 可能重新运行。

排查为什么改动没有让结果失效

当你认为自己改了输入，结果却仍然很快返回时，按下面的边界排查：

1. 确认包范围：检查命令末尾的包路径，避免修改了一个包却只运行另一个包。
2. 确认测试文件：修改是否真的落在当前构建会包含的 _test.go、构建标签或测试函数中。
3. 确认外部输入：测试如果读取模块目录内的文件或环境变量，Go 会把这些读取纳入缓存匹配；目录外的隐式输入不应被当成稳定的缓存键。
4. 确认命令参数：可缓存参数有明确范围，加入其他测试参数或普通参数可能让本次运行不再缓存，不能据此判断缓存机制异常。

需要查看 Go 的缓存判断细节时，可以临时打开调试开关：

# 临时打印测试缓存的判断信息；命令结束后不会永久修改项目配置。
GODEBUG=gocachetest=1 go test ./internal/order

调试日志适合定位“为什么命中”或“为什么没有命中”，不适合长期写进所有 CI 日志。先用 -count=1 证明测试本身的当前结果，再用这个开关解释缓存决策，排查路径会更短。

在本地调试与 CI 中选择合适命令

日常开发可以继续使用 go test ./...，因为成功结果缓存能减少重复执行成本。正在修改测试、怀疑旧结果掩盖回归时，使用 go test -count=1 ./...。只有当需要解释缓存键或调查环境差异时，才追加 GODEBUG=gocachetest=1。

CI 是否固定使用 -count=1，要看流水线目标。如果目标是每次都重新执行测试函数，可以明确写入 CI 命令；如果更重视速度和 Go 对输入的缓存判断，则保留默认命令，并在发现可疑差异时单独重跑一次。关键是把“快速复用”和“强制验证当前执行”当成两个明确的策略，而不是靠删除缓存目录碰运气。

结论

go test 出现 (cached)，表示 Go 复用了成功的包测试结果。需要强制重跑时，直接使用 go test -count=1；需要知道缓存为什么命中或失效时，再临时使用 GODEBUG=gocachetest=1。先区分缓存命中、测试未发现和测试失败，再按场景选择命令，通常不需要先清空整个构建缓存。

相关问题

为什么我改了代码，go test 还是很快结束？

先看摘要是否出现 (cached)，再确认修改属于当前包和构建条件。需要排除旧结果时，用 go test -count=1 直接重跑。

加了 -v 还会使用测试缓存吗？

-v 属于 Go 文档列出的可缓存测试参数之一，所以它本身不能用来强制绕过缓存；应显式加入 -count=1。

必须执行 go clean -testcache 吗？

不必把它作为首选。只想让当前命令再次执行时，-count=1 更直接；只有需要清理本地测试缓存状态时，才考虑单独的清理命令。