Go 工具链go test 缓存让失败用例看似没有执行怎么办

如果你修改了测试却仍然看到旧的失败输出，先不要急着删除整个 Go 缓存。go test 在包列表模式下会缓存成功的测试结果；命中时会重新展示之前的输出，并在摘要中显示 (cached)，测试二进制实际上没有再次运行。真正失败的测试结果不会因为这个机制被当作成功缓存。本文只围绕这个误判边界展开。

官方地址：https://go.dev/doc/

先看摘要：到底是缓存重放还是测试真的失败

官方对测试缓存的描述有一个很实用的线索：命中缓存时，go test 会显示以前的输出，并把耗时位置写成 (cached)。因此，下面两种结果不能混为一谈：

这里的关键不是“有没有看到熟悉的失败文本”，而是“这次命令有没有产生新的执行证据”。如果摘要标记了 (cached)，就应把它当作缓存命中线索，而不是把旧文本当作新一轮断言结果。

一次性确认：用 -count=1 绕过本次测试缓存

需要确认“修改后的测试是否真的执行”时，最小动作是给命令增加 -count=1：

# 只让本次测试重新运行，不删除整个构建缓存
go test -count=1 ./...

# 只定位一个包，减少输出，方便比较修改前后的结果
go test -count=1 ./internal/order

-count=1 是一次排查最合适的开关，因为它改变了测试命令的参数，直接阻止测试结果缓存复用。它不是“清空缓存”，也不会自动修复测试中的共享状态、随机数据或时间依赖。

如果去掉 -count=1 后又出现 (cached)，这通常反而说明测试结果缓存仍按预期工作。此时要继续确认测试是否依赖模块目录中的文件或环境变量：Go 会在这些输入保持不变时复用结果。测试读取了工作目录外的配置、数据库或网络服务时，缓存并不能替代对这些外部依赖的隔离。

需要证据时，对比三种缓存和调试开关

排查中不要把 go clean -cache、go clean -testcache 和 -count=1 当成同一个按钮。它们的影响范围不同：

# 打印测试缓存判断信息，便于定位“为什么复用”
GODEBUG=gocachetest=1 go test ./internal/order

# 需要进一步追踪哈希输入时再打开；输出会明显变多
GODEBUG=gocachehash=1 go test ./internal/order

官方还提供 GODEBUG=gocacheverify=1，它会绕过缓存并重建，再把结果与已有缓存进行比对。这个开关适合诊断缓存一致性，不适合每次开发测试都默认打开。

别把测试缓存、构建缓存和 vet 阻断混成一个问题

最容易误判的是“命令很快结束，所以测试没有跑”。快速结束可能来自三种不同原因：

• 测试结果缓存命中：摘要出现 (cached)，重点看 -count=1 或 gocachetest。
• 构建缓存复用：测试二进制的构建更快，但测试仍可能实际运行；不能只凭耗时判断。
• vet 或编译阶段失败：测试二进制还没有启动，应先看错误所属阶段，再决定是否临时隔离。

在 CI 中，通常保留默认缓存有利于速度，但要让失败重试具备明确证据：失败重跑可以临时追加 -count=1，同时保存完整命令和退出码。不要在每次流水线开始时无条件执行 go clean -cache，那会把构建复用也一并牺牲掉，却不能解决测试依赖外部状态的问题。

常见问题

失败的测试会被 go test 缓存吗？

常规包测试缓存主要复用成功的测试结果。看到旧失败文本时，先确认它是否是缓存重放的旧输出、当前命令的真实失败，或测试启动前的 vet/编译错误。

为什么加了 -run 仍然看到 cached？

-run 属于可缓存的测试参数，所以它本身不会关闭缓存。要强制本次执行，使用 -count=1。

什么时候用 go clean -testcache？

当你想删除本机保存的测试结果，或需要让后续命令统一从无 test cache 状态开始时使用。只想验证一次修改时，优先用 -count=1，影响更小。