Go test 明明改了代码却命中缓存怎么办

先说结论：go test 显示 (cached)，通常表示 Go 复用了上一次成功的测试结果，不代表源码一定没有改动。排查时先用 go test -count=1 ./... 做一次真实执行；如果结果发生变化，再检查改动是否在当前测试包的缓存输入范围内。不要一上来就删除整个构建缓存。

最快的判断顺序是：-count=1 绕过测试结果缓存，GODEBUG=gocachetest=1 查看缓存决策，最后才用 go clean -testcache 清理所有测试结果。

记住三个点：第一，测试缓存主要复用成功的包级测试结果；第二，包内文件和环境变量只有在内容没有变化时才会命中；第三，-count=1 是确认“到底有没有重新跑”的对照命令。

先判断 cached 到底说明什么

在包列表模式下，Go 会缓存成功的测试结果。再次运行时，如果测试二进制和可缓存参数对应的输入没有变化，命令会直接重放上次输出，并在摘要位置显示 (cached)。这和“编译器没有发现源码改动”不是一回事：源码改动通常会改变测试二进制，而测试依赖的外部文件或环境变量则要看是否被 Go 观测到。

测试里如果读取了模块目录下的配置文件，或者读取了环境变量，Go 会把这些访问纳入测试缓存判断。文件内容或环境值变化后，后续运行不应继续复用同一个成功结果。相反，测试依赖的包外文件、通过自定义程序间接读取的输入，可能不在你以为的缓存边界里。

用 -count=1 做一次干净对照

把日常命令改成下面这一条，只用于排查：

# 绕过测试结果缓存，确认测试函数是否重新执行
go test -count=1 -v ./path/to/pkg

# 多包排查时保留同样的对照条件
go test -count=1 ./...

如果加上 -count=1 后失败，说明之前的成功结果确实被缓存遮住了。此时先检查测试是否读取了刚改过的文件、环境变量是否在当前 shell 中更新，以及命令是否指向了正确的包。若仍然显示旧日志，重点看是否执行了别的包、生成的测试数据是否写到了包外目录。

-count=1 只影响这次命令，不会删除缓存。确认原因后，日常开发仍可去掉它，让没有输入变化的测试快速复用。

按缓存输入边界排查改动

缓存参数也有范围。官方列出的可缓存测试参数包括 -run、-short、-timeout、-v 等；加入不在这个集合中的测试参数或额外参数，会让这次结果不再进入测试缓存。不要把“没有 cached”误判成缓存失效故障，它有时只是参数本来就不可缓存。

看不出原因时打开缓存决策日志

如果改动边界不明显，可以让 Go 打印测试缓存决策：

# 输出测试缓存是否复用以及判断过程
GODEBUG=gocachetest=1 go test ./path/to/pkg

# 必要时查看更底层的哈希输入，输出会很多
GODEBUG=gocachehash=1 go test ./path/to/pkg

gocachetest=1 适合先看“为什么复用或不复用”；gocachehash=1 会打印构造缓存键时使用的内容哈希输入，信息量更大。不要把 GODEBUG 和普通业务环境变量混淆，它们分别控制 Go 运行时的诊断开关和测试本身读取的输入。

最后才清理 testcache

# 只移除已缓存的测试结果，不删除构建缓存
go clean -testcache

# 清理后重新运行，确认问题是否只是旧测试结果
go test -v ./path/to/pkg

go clean -testcache 适合缓存内容异常、需要统一复现环境，或你不想逐条判断输入时使用。它不会修复测试读取旧文件、环境变量没有传入、包路径错误等问题；如果清理后仍出现旧结果，应回到输入边界继续排查。

相关问题

为什么 go test -v 仍然会 cached？ 因为 -v 属于可缓存参数，详细输出本身不会强制重新执行；需要真实运行请加 -count=1。

改了测试依赖的数据库数据，为什么结果没变？ 远程数据库通常不是 Go 测试缓存自动追踪的输入。测试应显式准备独立数据，或用 -count=1 做排查，不能把远程状态当成缓存失效保证。

要不要每次都使用 -count=1？ 不建议。它适合排障和需要强制执行的场景；日常测试应保留默认缓存，把真正变化的源码、包内文件和环境变量纳入可观察输入。

因此，看到 (cached) 时先做对照、再查输入、最后清理。这个顺序既能快速确认测试是否执行，也能避免把构建缓存、测试缓存和测试数据问题混成一件事。