Go testing t.Parallel与t.Setenv冲突时的组织方式

在 Go 的表驱动测试里，先调用 t.Setenv 再调用 t.Parallel，并不能把两个动作安全地叠加。环境变量属于整个进程，t.Setenv 会登记清理动作；而 t.Parallel 会让测试进入并行调度。稳定的组织方式是：串行父级负责设置一次环境，并行子测试只读取；如果每个用例必须使用不同值，就不要继续修改进程环境，而是把配置显式传给被测函数。

先分清两个方法改变了什么

t.Parallel() 表示当前测试可以和其他并行测试同时运行，并会等待非并行测试阶段结束。t.Setenv(key, value) 则调用环境设置并在测试结束时恢复原值。后者影响的是整个测试进程，而不是当前 goroutine 的私有副本，所以并行测试不能把它当作局部变量使用。

真正容易漏掉的是祖先关系：子测试自己没有调用 t.Parallel 不代表它安全。如果上层测试已经并行化，子测试仍然位于并行祖先之下，此时也不应调用 t.Setenv。官方文档的边界可以在 https://pkg.go.dev/testing 查看。

固定环境用串行父级包住并行子测试

当一组用例共享同一个环境值时，把环境修改放在不调用 t.Parallel 的父级中。父级的 t.Run 会等并行子测试全部完成后才返回，因此环境的生命周期覆盖整个分组，清理也仍由 testing 接管。

func TestLookupWithTestMode(t *testing.T) {
	// 串行父级设置一次进程环境，退出时由 testing 自动恢复。
	t.Setenv("APP_MODE", "test")

	cases := []struct {
		name string
		want string
	}{
		{name: "cache", want: "test-cache"},
		{name: "api", want: "test-api"},
	}

	// 父级不调用 Parallel，子测试可以并行读取同一个稳定环境。
	for _, tc := range cases {
		tc := tc // 兼容旧版 Go 的循环变量捕获习惯。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			got := lookupFromEnv(tc.name)
			if got != tc.want {
				t.Fatalf("lookupFromEnv(%q) = %q, want %q", tc.name, got, tc.want)
			}
		})
	}
}

这个结构的关键不在于把 Setenv 写得更早，而在于让它位于并行祖先之外。所有子测试读取同一个值时，可以获得并行度；若某个子测试还要再次修改环境，整个分组就不再满足这个前提。

每个用例需要不同值时改成配置注入

如果一个用例要测试 APP_MODE=cache，另一个要测试 APP_MODE=api，就不能让它们并行地写进程环境。更稳妥的改法是把读取环境的动作放到边界层，在测试主体中传递一个配置对象。

type LookupConfig struct {
	Mode string
}

func lookup(name string, cfg LookupConfig) string {
	// 被测逻辑只依赖显式配置，不再隐式读取 os.Getenv。
	return cfg.Mode + "-" + name
}

func TestLookupByConfig(t *testing.T) {
	cases := []struct {
		name string
		cfg  LookupConfig
		want string
	}{
		{name: "cache", cfg: LookupConfig{Mode: "test-cache"}, want: "test-cache-cache"},
		{name: "api", cfg: LookupConfig{Mode: "test-api"}, want: "test-api-api"},
	}

	for _, tc := range cases {
		tc := tc // 每个闭包绑定自己的用例数据。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			if got := lookup(tc.name, tc.cfg); got != tc.want {
				t.Fatalf("lookup() = %q, want %q", got, tc.want)
			}
		})
	}
}

这种方式让并行测试之间只共享只读输入，不共享可变的进程状态。生产代码仍然可以在启动边界读取环境变量，再把结果组装成 LookupConfig；测试不必为了覆盖多个配置反复修改环境。

无法移除全局环境时按组串行隔离

有些旧代码只能通过 os.Getenv 读取，短期内改不了接口。这时不要用互斥锁把 t.Setenv 和 t.Parallel 硬绑在一起，因为 testing 的并行调度和环境清理仍然可能产生隐式交错。可以把同一环境值的用例放进不并行的分组，并让不同分组也保持串行。

func TestLegacyEnv(t *testing.T) {
	groups := []struct {
		name string
		mode string
	}{
		{name: "cache", mode: "cache"},
		{name: "api", mode: "api"},
	}

	for _, group := range groups {
		group := group // 保证闭包读取当前分组。
		t.Run(group.name, func(t *testing.T) {
			// 这里故意不调用 Parallel，避免进程环境与其他组交错。
			t.Setenv("APP_MODE", group.mode)
			assertLegacyLookup(t, group.name)
		})
	}
}

这会牺牲一部分并发度，但边界清楚、迁移成本低。完成接口改造后，再把读取环境的代码集中到启动层，测试主体就可以回到配置注入模式。

提交前的并行环境检查清单

可以先用 go test -run TestLookupWithTestMode -count=1 缩小范围，再用 go test -race ./... 做整体检查。这里的命令用于验证测试组织和数据竞争，不应被当作并行修改全局环境的补救手段。

相关问题

t.Setenv 会自动恢复原来的环境变量吗？

会。它通过 testing 的 Cleanup 在测试及其子测试结束后恢复原值，因此通常不需要再写 os.Unsetenv。

把 t.Setenv 写在 t.Parallel 前面就可以吗？

不可以。只要当前测试最终是并行测试，或者它有并行祖先，就不应调用 t.Setenv；调用顺序不能改变全局进程状态这一事实。

怎样同时覆盖多个环境值并保持并行？

优先在测试入口读取环境，再把不同值封装成配置参数传给被测函数。只有共享同一个固定值时，才适合用串行父级包住并行子测试。