Go testing.T Setenv 在并行测试中为什么不能直接使用

在 table-driven test 里给每个用例设置环境变量很常见，但只要测试链上出现 t.Parallel()，t.Setenv() 就不能直接跟着用。原因不是 API 不支持清理，而是环境变量属于整个 Go 进程：一个用例改了 os.Getenv 能看到的值，其他并行用例也可能同时读到它。Go 的 testing 包因此会主动拒绝这类组合。

先看最小冲突：Setenv 和 Parallel 不是相邻 API

下面的写法看起来只是“先准备环境，再加快测试”，实际会在调用 t.Parallel 时被测试框架拒绝：

func TestFeature(t *testing.T) {
	// Setenv 记录旧值，并注册测试结束后的恢复动作。
	t.Setenv("APP_MODE", "test")

	// 这不是并行安全的开关：环境变量会影响整个测试进程。
	t.Parallel()

	if got := os.Getenv("APP_MODE"); got != "test" {
		t.Fatalf("APP_MODE = %q", got)
	}
}

典型错误信息会指出：使用了 t.Setenv 的测试不能使用 t.Parallel。框架在这里宁可让测试立即失败，也不让一个偶发的环境串值变成难以复现的断言失败。

隐藏的第二条边界：祖先并行，子测试也不能改环境

更容易漏掉的是嵌套测试。父测试调用 t.Parallel 后，子测试即使没有写并行调用，也处于并行祖先之下：

func TestModes(t *testing.T) {
	// 父级并行后，所有子测试都不能修改进程级环境。
	t.Parallel()

	t.Run("sandbox", func(t *testing.T) {
		// 这里仍会被 testing 包拒绝，而不是获得独立环境。
		t.Setenv("APP_MODE", "sandbox")
	})
}

testing 内部会沿着当前测试的父级链检查并行状态。这个规则同样适用于测试内部自己启动的 goroutine：goroutine 并不会获得一份独立的进程环境，所以用锁包住读取只能减少部分竞态，不能把不同值安全地交给同时运行的用例。

三种修复方式：按隔离需求选择测试结构

如果测试的目标就是验证环境变量读取，最简单的办法是保留串行边界，不要在同一测试链上调用 t.Parallel：

func TestModes(t *testing.T) {
	for _, tc := range []struct {
		name string
		mode string
	}{
		{name: "sandbox", mode: "sandbox"},
		{name: "production-like", mode: "production-like"},
	} {
		t.Run(tc.name, func(t *testing.T) {
			// 子测试串行执行，Setenv 的共享影响不会与其他用例重叠。
			t.Setenv("APP_MODE", tc.mode)
			if err := loadModeFromEnv(); err != nil {
				// 失败时保留上下文，便于区分具体模式。
				t.Fatalf("load mode %q: %v", tc.mode, err)
			}
		})
	}
}

第二种方式更适合核心逻辑：把环境读取放在很薄的一层，业务函数接收显式配置。这样 table-driven test 可以并行，每个用例只操作自己的参数，不碰全局环境。第三种方式用于必须测试真实进程环境的场景：把每个场景放到独立子进程中，通过命令行参数或临时文件传入状态，代价是启动慢、断言和日志处理更复杂。

修复后的检查清单：别只把 Parallel 删掉

先从当前测试向上检查所有 t.Run 父级，再搜索同一测试文件是否有其他用例并行读取相同变量。随后重复运行测试，确认失败不会来自上一个用例残留的环境。Setenv 的恢复动作解决的是“测试结束后的回滚”，不是“多个测试同时使用不同值”的隔离。

常见问题

t.Setenv 会不会自动恢复环境变量？

会。它通过 Cleanup 在测试完成后恢复旧值，但这不改变修改期间的进程级共享属性。

把 t.Setenv 放到 t.Parallel 前面还是后面可以吗？

都不可以。前者会在后续调用 t.Parallel 时冲突，后者会直接触发并行测试限制。

测试内部用互斥锁包住 Setenv 能解决吗？

只能让修改动作排队，不能保证被测代码在锁外读取时仍看到自己的值。需要并行时应改为显式配置或子进程隔离。