Go testing.T.Setenv 的子测试环境变量恢复与并行边界

在 Go 测试里临时改环境变量，优先使用 t.Setenv("APP_MODE", "test")，不要手写 os.Setenv 和恢复逻辑。testing.T.Setenv 会保存原值，并把恢复动作注册到当前测试的清理阶段；当前测试及其子测试结束后，环境会回到进入测试前的状态。

先把 t.Setenv 放在正确的测试边界

这类测试最容易出错的地方不是 API 调用，而是修改范围。下面的写法把临时配置放到子测试内部，子测试结束后自动恢复；代码注释说明了恢复与并行限制。

func TestConfigMode(t *testing.T) {
	t.Run("test mode", func(t *testing.T) {
		// Setenv 保存旧值，并在这个子测试结束时注册恢复动作。
		t.Setenv("APP_MODE", "test")

		if got := os.Getenv("APP_MODE"); got != "test" {
			t.Fatalf("APP_MODE = %q, want test", got)
		}
		// 这里不要再调用 t.Parallel：环境变量影响整个进程。
	})
}

如果进入测试前没有 APP_MODE，清理时会删除它；如果原来有值，清理时恢复原值。与其在 defer 中猜测旧值是否存在，不如让测试框架管理这段生命周期。

调用 `t.Setenv` 修改的环境变量，会在当前测试用例全部跑完后自动恢复原值，不用手动写 defer 重置，但如果在子测试的并行逻辑里直接用 `t.Setenv` 很容易踩竞态坑，得严格遵守官方文档的边界约束。

父测试设置和子测试设置不是同一层恢复

父测试调用 t.Setenv 后再创建子测试，子测试会读到父测试的临时值；父测试的清理要等它和全部子测试都完成。若某个子测试需要另一份配置，应在子测试里再次调用 Setenv，不要直接改回父测试的值。

func TestBackend(t *testing.T) {
	// 父测试的值对子测试可见，直到父测试和所有子测试结束。
	t.Setenv("BACKEND", "memory")

	t.Run("file backend", func(t *testing.T) {
		// 子测试只在自己的生命周期内覆盖 BACKEND。
		t.Setenv("BACKEND", "file")
		if got := os.Getenv("BACKEND"); got != "file" {
			t.Fatalf("BACKEND = %q, want file", got)
		}
	})

	// file backend 子测试结束后，父测试仍应看到 memory。
	if got := os.Getenv("BACKEND"); got != "memory" {
		t.Fatalf("BACKEND after subtest = %q, want memory", got)
	}
}

这就是推荐的层级：父测试负责共同前置条件，子测试负责局部变体。测试中不要启动一个长期运行的 goroutine 去读取该变量并指望它自动同步；清理只负责测试框架能确定的生命周期。

多组环境配置用串行子测试隔离

表格驱动测试可以覆盖多种环境值，但这些子测试应该保持串行。每轮在自己的 t.Run 中设置变量，断言结束后让框架清理，再进入下一轮。

func TestFeatureFlag(t *testing.T) {
	cases := []struct {
		name  string
		value string
		want  bool
	}{
		{"enabled", "on", true},
		{"disabled", "off", false},
	}

	for _, tc := range cases {
		t.Run(tc.name, func(t *testing.T) {
			// 不调用 Parallel，避免不同轮次同时写同一个进程环境。
			t.Setenv("FEATURE_X", tc.value)
			if got := featureEnabled(os.Getenv("FEATURE_X")); got != tc.want {
				t.Fatalf("FEATURE_X=%q, enabled=%v, want %v", tc.value, got, tc.want)
			}
		})
	}
}

这种写法的关键不是“每个用例都重新启动进程”，而是把每次修改放在清晰的测试生命周期内。若被测代码会把环境变量读入包级缓存，还要在测试设计中显式提供重置入口，否则变量恢复了，缓存仍可能保留上一轮结果。

并行边界：进程环境变量不能和 t.Parallel 混用

Setenv 修改的是当前进程的环境，而不是某个 *testing.T 私有副本。因此官方文档明确限制：调用它的测试不能并行运行，拥有并行祖先的测试也不能调用它。下面两种结构要分开看：

如果确实需要并行验证不同配置，优先把配置改成显式参数或依赖注入；如果被测程序只能读取环境变量，则让这些用例留在串行测试组中。这里不要靠增加互斥锁来“修好” t.Setenv 的并行组合，因为测试框架本身已经把这种使用判定为不安全边界。

常见问题

t.Setenv 会不会影响下一个子测试？

正常不会。当前子测试结束后，Cleanup 会恢复进入前的值；但如果代码把环境变量缓存到包级变量，缓存需要单独重置。

为什么 t.Setenv 和 t.Parallel 不能一起用？

因为环境变量属于进程级状态，没有按测试隔离的副本。并行测试可能在恢复前读到另一组配置。

父测试设置环境变量后，子测试还要重复设置吗？

共同配置可以由父测试设置；只有需要覆盖成不同值的子测试才再次调用 Setenv，并保持该子测试串行。

排查环境变量测试时，按“设置在哪个测试、清理何时发生、是否存在并行祖先、被测代码是否缓存”四项检查，通常比手工添加更多恢复代码更快定位问题。