Go testing.T Setenv 怎么避免并行测试互相污染

遇到 Go 测试偶尔读到别的用例配置，先别急着给断言加重试。只要测试通过 t.Setenv 改了进程环境变量，它影响的就不是当前 goroutine；官方文档因此明确规定：调用它的测试不能是并行测试，也不能有并行祖先。

实用的分界线很简单：需要改环境变量的用例保持串行，用 t.Setenv 自动恢复；需要大量并行的用例不要碰进程环境，改成显式传入配置。只有在必须验证真实环境变量读取逻辑时，才考虑给每个用例启动独立子进程。

为什么 Setenv 会让 Parallel 测试变得危险

t.Setenv("APP_MODE", "test") 看起来像给当前测试设置局部变量，实际却调用了 os.Setenv。环境变量属于进程状态，其他 goroutine 和并行子测试都能看到同一份值。testing 再用 Cleanup 登记恢复动作，所以恢复发生在当前测试及其子测试结束后，而不是每次读取后立即撤销。

这也解释了为什么不能用“先 Setenv、再 Parallel”绕开限制：t.Parallel 之后测试会暂停并等待调度，期间共享状态仍可能被其他用例读取或修改。官方的约束不是语法偏好，而是把进程级状态和并行生命周期隔开。

串行测试怎样使用 t.Setenv 并自动恢复

如果被测代码只能从环境变量读取，最小安全写法是让测试保持串行，并把设置动作放在测试函数里。不要在这个测试或它的父测试中调用 t.Parallel；t.Setenv 会负责把旧值登记下来，测试结束后恢复。

func TestEndpointFromEnv(t *testing.T) {
	// 这个用例修改进程环境，因此保持串行。
	t.Setenv("APP_ENDPOINT", "https://test.example.invalid")

	got := endpointFromEnv()
	if got != "https://test.example.invalid" {
		t.Fatalf("endpointFromEnv() = %q; want test endpoint", got)
	}
	// 测试返回后，testing 会通过 Cleanup 恢复 APP_ENDPOINT 的旧值。
}

表驱动测试也可以继续使用，但不要把每一行都变成并行子测试。若同一测试函数要覆盖多个环境值，按顺序执行更容易读懂，也避免某个用例的恢复动作覆盖另一个用例的设置。

需要并行时，把环境变量移出进程全局

并行测试的首选方案是把环境变量转换成配置参数，让每个用例拥有自己的值。这样 t.Parallel 只并行计算，不再竞争 os.Environ 这类共享状态。

type AppConfig struct {
	Endpoint string
}

func endpoint(cfg AppConfig) string {
	// 业务函数依赖显式配置，不直接读取进程环境。
	return cfg.Endpoint
}

func TestEndpointParallel(t *testing.T) {
	cases := []struct {
		name     string
		endpoint string
	}{
		{name: "blue", endpoint: "https://blue.example.invalid"},
		{name: "green", endpoint: "https://green.example.invalid"},
	}
	for _, tc := range cases {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			// 每个子测试只使用自己的值，不修改进程环境。
			if got := endpoint(AppConfig{Endpoint: tc.endpoint}); got != tc.endpoint {
				t.Fatalf("endpoint() = %q; want %q", got, tc.endpoint)
			}
		})
	}
}

如果必须测试“程序启动时从环境变量读取配置”的真实链路，可把同一测试拆成子进程：父测试为 exec.Cmd.Env 组装独立环境，子进程执行一次检查后退出。它成本更高，但边界清晰；不要在并行父进程里反复调用 os.Setenv。

提交测试前的四项边界检查

最后用普通模式和并行模式各跑一次：go test ./... 检查整体行为，必要时再用 go test -count=10 ./... 放大偶发污染。这个命令只能帮助发现问题，不能把共享环境变量变成线程安全状态。

常见问题

Setenv 会不会只恢复变量值，不恢复变量是否存在？

它会记录原始状态，测试结束后恢复原值或原先的未设置状态，不需要手写清理代码。

可以先调用 Setenv 再调用 t.Parallel 吗？

不应该。官方约束要求使用 Setenv 的测试不能是并行测试；把调用顺序调换并不能消除进程级共享状态。

并行测试只能完全放弃环境变量吗？

不必。业务逻辑可改为配置注入；若必须覆盖启动读取，则让独立子进程接收自己的 Env。