测试环境变量

如果 Go 测试只需要临时改一个环境变量，可以使用 t.Setenv。但只要当前测试、父测试或祖先测试调用过 t.Parallel()，就不能再使用它。原因不是恢复动作不可靠，而是环境变量属于整个进程的共享状态：并行测试运行期间，其他测试可能同时读到这次修改。

官方文档：https://pkg.go.dev/testing

需要环境变量时，默认把使用 t.Setenv 的测试保持为串行；确实要并行，就把配置改成显式参数，或把需要全局环境的动作放进独立进程。

t.Setenv 改的是整个测试进程

t.Setenv 本质上调用环境变量设置，并注册清理函数，在测试返回后恢复旧值。这个生命周期很方便，但“测试结束后恢复”并不等于“测试执行期间互不影响”。只要修改尚未恢复，所有运行在同一进程中的代码都可能观察到新值。

func TestEndpointFromEnv(t *testing.T) {
	// Setenv 会在本测试结束时恢复 ENDPOINT_URL 的旧值。
	t.Setenv("ENDPOINT_URL", "https://example.test")

	got := endpointFromEnv()
	if got != "https://example.test" {
		// 失败信息保留实际值，方便区分未设置和读取了错误配置。
		t.Fatalf("endpoint = %q, want %q", got, "https://example.test")
	}
}

这段写法适合串行测试。它的安全边界是“同一时间没有其他测试依赖这个进程级变量”，而不是变量最终会被还原。

为什么和 t.Parallel 冲突

t.Parallel() 会把当前测试标记为可与其他并行测试同时运行。若这时再调用 t.Setenv，testing 包会直接拒绝这种组合；父测试已经并行化时，子测试即使没有显式调用 t.Parallel，也不能使用会影响全局进程状态的操作。

func TestConfigCases(t *testing.T) {
	// 父测试进入并行作用域后，子测试不能再调用 t.Setenv。
	t.Parallel()

	t.Run("production", func(t *testing.T) {
		// 这里会与并行作用域冲突，不要把 Setenv 放在此处。
		t.Setenv("APP_MODE", "production")
	})
}

冲突发生在“修改进程共享状态”和“允许并发执行”之间。即便两个子测试设置的是不同变量，也不能据此认为它们安全：被测代码、初始化逻辑或依赖库可能读取其他环境变量，清理顺序也不能解决并发读取时机的问题。

并行测试的三种改写方式

如果测试数量较多，建议先让被测函数接收配置，再决定是否需要进程隔离。最容易维护的方案是显式注入配置，让每个并行测试拥有自己的输入：

type Config struct {
	// Endpoint 属于一次调用的输入，不再依赖进程环境。
	Endpoint string
}

func endpoint(cfg Config) string {
	// 业务函数只使用传入配置，多个测试可以同时传不同值。
	return cfg.Endpoint
}

func TestEndpointParallel(t *testing.T) {
	for _, tc := range []struct {
		name string
		url  string
	}{
		{name: "one", url: "https://one.test"},
		{name: "two", url: "https://two.test"},
	} {
		tc := tc
		t.Run(tc.name, func(t *testing.T) {
			// 每个子测试只使用自己的值，可以安全并行。
			t.Parallel()
			if got := endpoint(Config{Endpoint: tc.url}); got != tc.url {
				// 断言失败时同时报告用例名和实际配置。
				t.Fatalf("endpoint = %q, want %q", got, tc.url)
			}
		})
	}
}

三种边界可以这样选：

容易误判的两个边界

第一，t.Cleanup 只能负责收尾，不能把一次并发期间的全局修改变成局部变量。第二，子测试没有写 t.Parallel 也不代表一定安全；只要父级已经并行化，testing 包仍会阻止 Setenv 这类进程级操作。

如果只是希望不同用例读取不同环境值，优先改造为配置参数。如果第三方代码固定调用环境读取函数，才考虑把那组用例集中为串行测试，或通过独立进程隔离。这样既保留并行测试的收益，也不会把偶发的全局状态污染误认为业务错误。

相关问题

t.Setenv 会自动恢复吗？

会。testing 会登记清理动作，在当前测试结束后恢复原值；但恢复发生在测试结束之后，不能保护并行运行期间的其他测试。

能不能先 t.Setenv 再 t.Parallel？

不能。只要测试使用了 t.Setenv，后续再进入并行测试也会被 testing 拒绝，应改为串行，或移除进程环境修改。

并行测试一定要启动子进程吗？

不一定。被测函数可改造时，显式传入配置通常更简单；只有依赖固定读取进程环境且无法注入时，独立进程才更合适。