Go test 显示 cached 时为什么看不到刚改的环境

如果 go test ./... 显示 (cached)，你刚改的环境变量没有反映出来，先别急着怀疑 os.Getenv。这通常表示 Go 复用了之前的成功测试结果。最直接的复查命令是把变量放在命令前设置，并用 -count=1 强制真实运行：

FEATURE_MODE=beta go test ./... -count=1
# -count=1 只用于本次复查，避免拿旧的成功结果下结论

环境变量只有在测试实际读取它，并且它的值确实改变了缓存输入时，才会让缓存不再命中；排障时优先用 -count=1，不要把清空所有缓存当成第一反应。

为什么环境变量有时会进入测试缓存输入

Go 的测试缓存不是简单按“目录有没有改动”判断。显式传入包列表，例如 go test ./... 或 go test .，属于 package list mode；通过的测试结果可以被缓存，命令再次匹配时就显示 (cached)。只运行当前目录而不带包参数时，缓存规则不同，不能把两种模式混为一谈。

缓存匹配先看测试二进制和允许缓存的测试参数，再看测试运行期间真正读过的输入。测试调用 os.Getenv("FEATURE_MODE")，Go 就有机会把这个变量的值纳入后续匹配；测试打开模块内文件时，文件内容也会成为输入。反过来，若你只在 shell 里改了一个测试根本没有读取的变量，它不会自动让结果失效。

先用证据判断，再决定是否绕过缓存

排查时建议把“缓存是否命中”和“业务断言是否正确”分开。先用下面的命令观察 Go 的测试缓存决策：

GODEBUG=gocachetest=1 go test ./pkg/config -run TestFeatureMode -v
# 只增加缓存决策线索，不把调试输出写进测试断言

FEATURE_MODE=beta go test ./pkg/config -run TestFeatureMode -count=1 -v
# 明确绕过缓存，验证 beta 是否被本次测试真正读到

第一条命令适合回答“为什么复用或没有复用”，第二条适合回答“改后的环境能不能让测试通过”。不要用带有旧值的命令结果替代第二条的复查证据。若缓存目录里积累了大量旧测试结果，可以单独执行 go clean -testcache，但它的影响范围比当前测试更大；只为验证一个环境变量时，-count=1 更容易复现。

让环境驱动测试不再产生错觉

测试如果依赖环境变量，应在测试体内明确读取，并让每个用例设置自己的输入。不要依赖开发者当前 shell 中碰巧存在的值，也不要在并行测试之间共享可变环境。需要临时设置时，可以用 t.Setenv，让测试结束后恢复环境：

func TestFeatureMode(t *testing.T) {
	// 每个用例声明自己的环境输入，避免依赖开发机的旧值。
	t.Setenv("FEATURE_MODE", "beta")

	mode := os.Getenv("FEATURE_MODE")
	// 断言读取结果，确保测试确实消费了这个缓存输入。
	if mode != "beta" {
		t.Fatalf("FEATURE_MODE = %q, want beta", mode)
	}
}

这里的关键不是让所有测试都关闭缓存，而是让输入可见、可重复。遇到“刚改环境但输出 cached”，按“确认 package list mode → 确认变量被读取 → 用 -count=1 复查 → 再决定是否清理缓存”的顺序走，通常能把误判快速收窄。

相关问题

为什么加了 -v 还是可能看到 cached？

-v 属于可缓存的测试参数，不能把它当成关闭缓存的开关。需要真实执行时使用 -count=1。

改了测试文件后还会复用旧结果吗？

测试二进制发生变化通常会改变缓存匹配条件；但如果改动的是测试外部读取的文件、环境或命令输入，仍应按实际读取路径复查。

go clean -testcache 和 -count=1 怎么选？

单次验证选 -count=1；需要让本机已有测试结果整体失效时再用 go clean -testcache，并记录这次清理的范围。