Go go test cache 命中缓存后为什么没有重新执行

执行 go test ./... 后看到 (cached)，通常不是测试“没有执行成功”，而是 Go 复用了之前一次成功的包测试结果。先记住两个边界：测试结果缓存主要发生在带包列表的模式中；最直接的一次性强制重跑方式是 go test -count=1 ./...。如果强制重跑后仍然没有你期待的变化，再去检查测试实际读取的文件、环境变量和命令参数。

先确认是否真的命中测试缓存

先在模块根目录执行：

go test ./... # 使用包列表模式，让 Go 检查各包的成功测试结果缓存
go test -count=1 ./... # 只对本次命令禁用测试缓存

第一条命令的包摘要如果出现 (cached)，说明 Go 找到了匹配的成功结果，并重新展示之前的输出。第二条命令不应该以 (cached) 作为本次摘要标记。注意，单独执行 go test 属于本地目录模式，不能简单拿它和 go test ./... 的缓存表现比较。

按测试二进制、参数和输入判断缓存键

缓存不是只看某个 _test.go 文件的修改时间。Go 会先判断测试二进制是否相同，再结合命令行中允许缓存的测试参数；测试运行时如果读取了模块目录内的文件或环境变量，这些输入也会参与后续匹配。

因此，“我改了配置但测试没重跑”要分两种情况：如果配置文件被测试用 os.ReadFile 读取，内容变化通常会影响匹配；如果配置只由测试外部服务读取，Go 未必知道它变化，测试仍可能命中旧结果。这是测试缓存最容易让人误判的边界。

用 -count=1 临时强制执行一次

需要确认测试本身是否产生了新结果时，优先使用：

go test -count=1 -v ./... # -count=1 禁用本次结果复用，-v 展示测试日志

这是排障开关，不等于删除缓存。它适合验证“测试代码是否真的被执行”“外部依赖是否返回了新值”等问题。确认原因后，持续集成脚本不应为了掩盖不稳定测试而无条件加上它；否则会失去缓存带来的反馈速度。

用 GODEBUG 和 go clean -testcache 定位持久缓存问题

如果命中关系仍然不清楚，可以打开缓存决策日志：

GODEBUG=gocachetest=1 go test ./... # 输出 Go 对测试缓存复用与失配的判断细节
go clean -testcache # 让已有测试结果失效，不清理编译产物

前一条适合先观察，后一条适合确认“旧的成功结果是否造成了错觉”。不要把 go clean -cache 当成默认处理，它会清理整个构建缓存，范围比测试结果大得多。若你只想让单次命令重新运行，仍然是 -count=1 更稳妥。

常见问题

为什么改了测试调用的外部接口，仍然显示 cached？

Go 只能跟踪测试二进制、可缓存参数，以及测试显式读取到的部分输入。外部接口数据变化不一定进入缓存键，先用 -count=1 验证。

go clean -testcache 会删除依赖模块吗？

不会。它让测试结果缓存失效，模块下载缓存和构建缓存仍是不同范围。

为什么加了一个参数后反而每次都执行？

并非所有测试参数都可缓存。超出可缓存集合的参数会使这次测试不再复用成功结果。