Go test 缓存让修改后的测试看起来没执行怎么办

改了测试代码，运行 go test ./... 却几乎瞬间结束，最常见的原因不是测试“没有被发现”，而是 Go 复用了包列表模式下的成功测试结果。看到摘要里的 (cached)，就可以先按缓存命中处理。

先确认你是否进入了可缓存的包列表模式

Go 的 go test 有一个容易忽略的区别：没有包参数时，它在当前目录编译并运行测试；带有 .、./pkg 或 ./... 时，则会按包列表处理。只有后者会缓存成功的包级测试结果。

因此下面两条命令的缓存语义不同：

# 当前目录模式：适合临时观察当前包，默认不走测试结果缓存
go test

# 包列表模式：成功结果可能进入并命中测试缓存
go test ./...

这不是说 Go 忽略了源文件。测试二进制、命令行中可缓存的测试参数，以及测试读取到的包内文件和环境变量，都会参与缓存匹配。真正需要先问自己的问题是：这次命令是否带了包参数，以及结果行有没有 (cached)。

用输出判断是缓存命中还是测试真的很快

在包列表模式中，命中缓存时 Go 会重新显示之前的输出，并在摘要中用 (cached) 代替耗时。没有 (cached) 只能说明当前输出没有明确标记缓存，不能单凭“很快”断言测试一定执行了。

-v 可以显示更完整的测试日志，但它本身仍属于可缓存参数；加了 -v 不等于强制重跑。类似地，-run 只是缩小测试选择范围，也可能复用对应的成功结果。

先把问题缩小到一个包和一个测试，再做一次对照最容易：

# 先观察指定测试；中文注释说明过滤范围，避免把整棵模块树混在一起
go test -run '^TestCacheKey$' ./internal/config

# 再显式禁用测试缓存；-run 仍保留，便于比较同一个测试
go test -count=1 -run '^TestCacheKey$' ./internal/config

强制重跑时优先使用 -count=1

-count=1 是最直接、最容易复查的处理方式。它只改变本次测试执行策略，不需要删除本机的其他构建产物。排查“我刚改的断言为什么没生效”时，建议先执行：

# 只让这次全包测试绕过成功结果缓存，保留包选择
go test -count=1 ./...

# 只重跑一个测试；中文注释强调这是确认修改是否生效的对照命令
go test -count=1 -run '^TestCacheKey$' ./internal/config

如果第二次输出不再出现 (cached)，并且失败位置或日志反映了刚才的修改，说明之前的“没执行”主要是缓存错觉。若仍看不到预期变化，就继续检查构建标签、测试文件命名、包路径和 -run 正则，而不要反复清缓存。

复杂情况用调试开关或精确清理

当一个团队在不同机器上看到不一致结果，可以打开 Go 命令的缓存诊断信息：

# 打印 Go 对测试结果是否复用的判断细节；输出可能较多，适合一次排障
env GODEBUG=gocachetest=1 go test ./internal/config

如果确认本地测试结果缓存本身需要失效，再使用：

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

go clean -cache 的范围更大，会删除整个 Go 构建缓存，通常不是“测试看起来没执行”的第一选择。清理之后还要重新运行测试；清理动作本身不能替代对命令模式的判断。

别把外部依赖变化误认为 Go 缓存失效

Go 能根据测试二进制、可识别的参数、包内文件和环境变量判断是否可以复用结果，但它不会替你理解数据库远端数据、系统时钟、外部 HTTP 响应或随机服务状态。测试如果依赖这些输入，即使业务世界已经变了，命令也可能仍然符合缓存条件。

这类测试有两个选择：让依赖变成显式的测试输入，或在需要新鲜结果的场景统一使用 -count=1。CI 可以把它写进测试脚本，开发机则只在排障和依赖外部状态时使用，避免每次都失去缓存带来的速度。

常见问题

看到 ok 就一定是缓存吗？

不是。ok 只表示成功；摘要明确出现 (cached) 才是 Go 告知你复用了缓存结果。

为什么加了 -v 还是像没重新执行？

-v 负责显示日志，并不负责关闭测试缓存。需要新执行时显式加 -count=1。

go clean -testcache 会删除编译结果吗？

不会。它针对测试结果缓存；普通构建缓存由 go clean -cache 管理，清理范围更大。

实际排查可以固定成一条短路径：先看包参数和 (cached)，再用同一筛选条件执行 -count=1，最后才用 GODEBUG 或精确清理确认缓存来源。这样既能确认修改已经进入测试，也不会把构建环境无关地清空。