Go testing.TB Setenv 和 t.Cleanup 如何配合

我在给配置驱动的 Go 代码补测试时，最容易踩到的坑不是环境变量怎么写，而是测试结束后谁负责恢复。现在更稳的组合是：用 t.Setenv 设置临时值，把额外的全局替身、临时文件等交给 t.Cleanup；不要手写一套容易漏掉的恢复分支。需要特别记住，环境变量属于整个进程，调用了 t.Parallel() 或处于并行祖先下面时，不能使用 Setenv。

Setenv 先解决环境变量恢复，Cleanup 再接管关联状态

testing.TB 是 *testing.T、*testing.B 和 *testing.F 的共同接口。它的 Setenv(key, value) 会设置进程环境，并在测试及其子测试完成后恢复原状态。对普通单元测试来说，入口通常只需要这一句：

func TestConfigFromEnv(t *testing.T) {
	// Setenv 会记住进入测试前的状态，并自动注册恢复动作。
	t.Setenv("APP_MODE", "test")

	if got := os.Getenv("APP_MODE"); got != "test" {
		// 失败信息保留实际值，便于区分键名错误与清理问题。
		t.Fatalf("APP_MODE = %q, want %q", got, "test")
	}
}

如果测试开始前 APP_MODE 是 prod，测试结束后会回到 prod；如果它原本不存在，结束后会恢复为“未设置”。这正是手写 old, existed := os.LookupEnv(...) 时最容易漏掉的分支。

把临时替身和环境变量放进同一套清理边界

我更愿意把“测试期间改变的状态”集中放在测试函数开头，把“撤销状态”的代码紧跟注册。比如配置读取函数依赖环境变量，同时还要替换一个包级函数：

func TestLoadConfig(t *testing.T) {
	t.Setenv("APP_MODE", "test")

	oldReader := readConfigFile
	readConfigFile = func(string) ([]byte, error) {
		// 测试替身只返回最小输入，避免依赖真实文件。
		return []byte(`mode: test`), nil
	}
	t.Cleanup(func() {
		// Cleanup 负责恢复包级状态，避免污染后续测试。
		readConfigFile = oldReader
	})

	got, err := LoadConfig()
	if err != nil {
		// 错误必须在读取结果前处理，避免用空结果掩盖根因。
		t.Fatalf("LoadConfig() error = %v", err)
	}
	if got.Mode != "test" {
		t.Fatalf("Mode = %q, want %q", got.Mode, "test")
	}
}

这里的职责很清楚：Setenv 管环境变量，Cleanup 管自定义替身。不要因为两者都能“恢复”就把 os.Setenv、os.Unsetenv 和多个条件分支混在测试结尾；测试中途 Fatal 或子测试失败时，统一清理更不容易遗漏。

多个 Cleanup 为什么要按后注册先执行

Cleanup 是后进先出（LIFO）。如果自定义清理依赖环境变量仍保持测试值，就先注册环境变量，再注册自定义清理：自定义清理后执行，环境恢复最后执行。

func TestCleanupOrder(t *testing.T) {
	t.Setenv("APP_MODE", "test") // 先注册环境恢复

	t.Cleanup(func() {
		// 该回调执行时仍可读到 test，适合记录或关闭依赖配置的资源。
		if os.Getenv("APP_MODE") != "test" {
			t.Errorf("APP_MODE was restored too early")
		}
	})

	// 后注册的回调先执行；Setenv 的恢复动作随后执行。
}

如果自定义清理不依赖环境值，注册先后通常不重要；如果它要关闭一个按环境创建的客户端，就必须把依赖关系写成注册顺序，并在代码旁留下短注释。另一个边界是：不要在 Cleanup 中启动依赖当前测试生命周期的异步工作，回调应完成释放而不是把清理继续甩给后台 goroutine。

并行测试、缺失变量和失败路径怎么检查

官方限制不是“建议”，而是使用边界：Setenv 影响整个进程，不能和并行测试混用。下面这张小表足够作为提交前检查单：

实践中可以把环境读取改成函数参数或配置对象，让真正需要并行的测试不依赖进程环境。只有在验证“程序确实从环境读取配置”这一层时，才用 Setenv；其余业务测试优先传入配置值，边界更小。

相关问题

testing.TB 能直接调用 Setenv 吗？

可以。TB 是测试、基准和模糊测试共享的接口；只要具体实现支持该方法，就能复用设置和清理环境变量的辅助函数。

Setenv 和手写 t.Cleanup 哪个负责恢复变量？

Setenv 已经负责环境变量的恢复；手写 t.Cleanup 应用于额外的全局状态、替身或资源，不要重复恢复同一个键。

为什么 Setenv 不能放在 Parallel 测试里？

因为环境变量是进程级共享状态，并行测试可能同时读到彼此的值。需要并行时，把配置改成参数或独立对象传入。