t.Parallel 测试共享环境变量的隔离方案

在 Go 测试里，t.Parallel() 只适合让测试逻辑并行执行，并不会把进程环境变量变成测试私有数据。t.Setenv() 修改的是整个测试进程的环境，还会在清理阶段恢复原值，所以它不能出现在并行测试或有并行祖先的测试中。可靠方案是：并行分支只接收只读配置；确实要改变环境的场景则放到非并行边界，或交给独立子进程。

为什么 t.Setenv 会和 t.Parallel 发生冲突

并行测试的危险点不在于 os.Getenv 本身，而在于写入动作的作用域。两个测试即使运行在不同 goroutine 中，也仍然共享同一个测试进程；其中一个测试把 APP_MODE 改成 staging，另一个测试读取到的可能就是这个临时值。清理函数只能在测试结束时恢复，无法阻止中间窗口的交叉读取。

先把测试资源按作用域列一遍，通常比盲目加锁更有效：

把环境读取改成并行测试的显式依赖

如果环境变量只是配置来源，不要在每个并行用例里反复读取和修改。可以在进入并行逻辑前读取一次，再将配置作为参数传入。这样每个测试拿到的是自己的值，业务函数也更容易在没有真实环境的情况下测试。

type Config struct {
	// Config 是测试期间只读的业务配置，不保存 os.Getenv 的写操作。
	Mode  string
	Cache string
}

func loadConfig() Config {
	// 只在准备阶段读取环境，后面的并行逻辑不再改环境。
	return Config{Mode: os.Getenv("APP_MODE"), Cache: os.Getenv("CACHE_URL")}
}

func TestRegions(t *testing.T) {
	cfg := loadConfig()
	for _, name := range []string{"east", "west"} {
		name := name
		t.Run(name, func(t *testing.T) {
			t.Parallel()
			// 并行分支只消费自己的只读副本，不调用 t.Setenv。
			if err := checkRegion(cfg, name); err != nil {
				t.Fatal(err)
			}
		})
	}
}

这里的关键不是把 Config 声明成全局变量，而是让依赖沿函数参数传递。若配置还包含 map、slice 或指针，组装完成后不要继续修改；需要变更时，为当前用例复制一份。

文件、缓存和客户端也要拥有自己的边界

只处理环境变量仍然不够。并行测试经常因为共享临时文件名、固定缓存键或复用带内部状态的客户端而互相影响。t.TempDir() 会为当前测试提供独立目录，并在测试及其子测试结束后清理；它适合放置导入文件、锁文件和中间结果。

func TestImport(t *testing.T) {
	t.Parallel()
	root := t.TempDir()
	cacheKey := "import:" + t.Name()
	// 当前用例独占目录和缓存键，避免并行分支覆盖彼此的数据。
	if err := runImport(root, cacheKey); err != nil {
		t.Fatalf("导入失败: %v", err)
	}
}

如果被测代码内部使用固定全局缓存，测试侧不要用 sleep 等待“让它稳定”。应把缓存接口抽成依赖，测试注入内存实现；无法改造时，降低该组测试的并行度，并在代码评审中记录这个隔离缺口。

必须切换环境时用子进程建立隔离

有些场景就是要验证不同环境变量下的启动行为，例如配置解析、命令行入口或初始化失败路径。这时不要让当前测试进程反复调用 t.Setenv，而是启动子进程，通过 Cmd.Env 传入一份完整环境。主进程的并行测试不会直接看到子进程的修改。

func runWithMode(t *testing.T, mode string) []byte {
	t.Helper()
	cmd := exec.Command(os.Args[0], "-test.run=TestHelperProcess")
	// 复制宿主环境，只替换当前子进程需要的键。
	cmd.Env = append(os.Environ(), "APP_MODE="+mode, "GO_TEST_HELPER=1")
	out, err := cmd.CombinedOutput()
	if err != nil {
		// 保留子进程输出，便于区分配置失败和测试框架失败。
		t.Fatalf("子进程失败: %v\\n%s", err, out)
	}
	return out
}

func TestHelperProcess(t *testing.T) {
	// 非目标启动路径直接返回，避免普通测试递归启动自己。
	if os.Getenv("GO_TEST_HELPER") != "1" {
		return
	}
	// 这里调用真正的入口检查 APP_MODE，然后正常退出。
	startApplication()
}

子进程方案的成本是启动更慢、日志需要单独收集，且必须防止辅助测试递归。它适合验证启动期行为，不适合替代所有普通单元测试。

用重复执行和竞态检查确认隔离有效

修改完成后，先让同一包重复运行，再扩大并行度观察是否出现偶发失败：

# 重复执行并行测试，尽早暴露环境和缓存残留。
go test -count=30 -run 'TestRegions|TestImport' ./...
# 用竞态检测器检查共享 map、客户端和清理逻辑。
go test -race -count=5 ./...

若失败只在重复运行中出现，优先检查固定环境变量、固定文件名、包级变量和缓存键；若 -race 报告写冲突，修复数据所有权，不要只延长等待时间。隔离的验收标准是：每个并行用例的输入可描述、资源可清理、失败日志能指向具体边界。

相关问题

t.Parallel 后还能调用 t.Setenv 吗？

不能。官方 testing 文档明确说明，Setenv 影响整个进程，因此不能用于并行测试或有并行祖先的测试。

只读调用 os.Getenv 也会造成竞争吗？

单独读取通常不是问题，风险在其他测试同时修改同一进程环境。只要测试组中存在写环境的场景，就应把写入移出并行边界或改用子进程。

为什么 t.TempDir 比手写临时目录更适合并行测试？

它为当前测试分配独立目录并绑定清理生命周期，减少目录名碰撞和残留文件；但固定外部缓存键仍需另外隔离。