Go go test cache 环境变量变化会不会使测试缓存失效

会失效，但不是“命令行里所有环境变量一变，缓存就全部失效”。在包列表模式下，go test ./... 只缓存成功的测试结果；如果测试通过 os.Getenv 或 os.LookupEnv 查询了某个变量，Go 会把这次查询记录为测试输入。下次运行时，只要该变量的值改变，或者从“未设置”变成“已设置但为空”，就不能复用原来的结果。

Go go test cache 环境变量变化会不会使测试缓存失效

先把结论落到使用场景：下面两次命令都处于包列表模式，第一次实际运行，第二次才可能出现 (cached)。

# 显式给出包列表，go test 才有机会复用成功结果
go test ./...
go test ./...

# 只做一次不使用测试缓存的对照运行
go test -count=1 ./...

如果测试读取了 APP_ENV，先用 APP_ENV=dev go test ./...，再改为 APP_ENV=prod，第二次通常会重新执行。改回 dev 后，之前那份成功结果仍可能再次命中，前提是测试二进制、可缓存参数和其他输入也没有变化。

测试到底记录了哪个环境变量

Go 的测试缓存不是简单地把 os.Environ() 整体做哈希。测试运行期间，标准库会通过测试日志回传环境变量查询，go 命令在下一次查缓存时重新计算这些变量的状态。因此，测试没有读过的变量改变，通常不会单独造成这份测试结果失效。

package config_test

import (
	"os"
	"testing"
)

func TestMode(t *testing.T) {
	// LookupEnv 同时保留“是否存在”和“值”，便于区分未设置与空值。
	value, exists := os.LookupEnv("APP_ENV")
	if !exists {
		value = "default"
	}
	// 这次读取会成为 go test 缓存输入；APP_ENV 改变后不要期待直接命中旧结果。
	t.Logf("mode=%q exists=%t", value, exists)
}

这也解释了一个容易忽略的情况：APP_ENV 未设置、APP_ENV= 为空、APP_ENV=dev 是三种不同输入。实现使用 os.Getenv 时，业务代码可能只看到空字符串；缓存层仍能区分“变量不存在”和“变量存在但为空”。

环境变量变化和其他缓存条件怎么区分

排查时不要只盯着环境变量。官方规则要求测试结果来自同一个测试二进制，命令参数也只能使用可缓存的测试参数；本地目录模式则直接关闭测试缓存。

注意：-timeout 属于可缓存参数，但缓存结果会被视作几乎瞬间完成，所以调大超时并不能让旧测试重新跑一遍；需要新鲜执行时直接用 -count=1。

用调试开关确认是否命中缓存

当 CI 和本地结果不一致时，先保留同一包、同一 -run 参数，只打开 Go 提供的诊断信息：

# 输出 go test 是否复用缓存以及未命中的原因
GODEBUG=gocachetest=1 go test ./path/to/pkg

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

# 用一次强制执行建立新的对照结果
APP_ENV=prod go test -count=1 ./path/to/pkg

gocachetest=1 适合回答“为什么没有出现 cached”；gocachehash=1 会打印大量参与哈希的输入，适合进一步确认变量名、文件或命令参数。排完问题后不要把诊断开关无条件塞进日常 CI，否则日志会明显变长。

相关问题

只改变没有被测试读取的环境变量，会让缓存失效吗？

通常不会单独让该测试结果失效，因为它没有进入测试输入记录；但构建脚本、测试启动器或下游程序可能间接读取它，遇到疑问应以诊断输出为准。

为什么第二次还是没有出现 (cached)？

先确认使用了包参数、上次确实成功、没有传入不可缓存的测试参数，并确认测试是否修改或读取了模块内文件。

清空缓存和强制重跑有什么区别？

-count=1 只影响当前命令；go clean -testcache 会清除所有测试结果缓存，范围更大，通常不必作为第一步。

事实依据：go help test 的测试缓存说明、Go 官方 cmd/go/internal/test 源码及 internal/testlog 机制。本文示例只展示缓存输入边界，不把生成图当作真实运行截图。