Go 测试里的临时文件和环境变量怎么清理：t.TempDir、t.Setenv、t.Cleanup 工作流

Go 测试里手动创建目录、手动改环境变量，最容易留下两个隐患：本次测试生成的文件影响下一次运行，或者某个配置值串到别的用例里。把临时目录交给 t.TempDir，环境变量交给 t.Setenv，资源关闭交给 t.Cleanup，能让测试结束时自动把现场全部清理干净。

先识别问题：测试为什么会“单独跑过、一起跑失败”

常见表现是本地单独跑单条用例没问题，CI 连续跑或者加上 -count=2 之后就开始报错。原因通常不是断言逻辑本身出错，而是多个用例共享了进程级状态：写死的固定 /tmp/app-test 目录、没有恢复的 APP_MODE，或者启动之后忘记关闭的临时服务。

手动写 defer 清理逻辑也不是完全不能用，但当测试包含子测试、用例提前调用 t.Fatal 终止、或者资源创建逻辑分散在各个辅助函数里的时候，清理逻辑很容易出现遗漏。testing 包提供的原生方法能把资源的生命周期和当前测试对象直接绑定，读代码的时候也能很清晰的看到谁负责收尾工作。

一套最小写法：目录、配置和清理放在同一个测试里

下面的例子为配置加载逻辑准备独立文件夹和临时环境变量。目录由 t.TempDir 创建，变量由 t.Setenv 设置；测试结束后两者都会按照 testing 包的规则自动完成收尾。

func TestLoadConfig(t *testing.T) {
    dir := t.TempDir()
    t.Setenv("APP_CONFIG_DIR", dir)

    file := filepath.Join(dir, "app.json")
    if err := os.WriteFile(file, []byte(`{"mode":"test"}`), 0o600); err != nil {
        t.Fatal(err)
    }

    cfg, err := LoadConfig()
    if err != nil {
        t.Fatal(err)
    }
    if cfg.Mode != "test" {
        t.Fatalf("mode = %q", cfg.Mode)
    }
}

这段测试不需要在末尾额外写删除存储路径的代码，也不用自己把旧的环境变量存下来再恢复。要注意的是，t.Setenv 修改的是整个测试进程的环境，因此它不能和 t.Parallel 混用，也不能放在已经标记并行的父测试下面。

需要额外收尾时，用 t.Cleanup 把责任贴近创建点

有些资源不属于临时目录范畴，比如测试用的 HTTP 服务、数据库事务或者修改过的包级变量。资源在哪里创建，就在紧邻的位置注册 t.Cleanup，不用把所有清理代码都集中堆在测试函数的末尾。

srv := httptest.NewServer(handler)
t.Cleanup(srv.Close)

oldLevel := currentLevel
currentLevel = "debug"
t.Cleanup(func() {
    currentLevel = oldLevel
})

Cleanup 的调用顺序和注册顺序相反，这个特性很适合处理有依赖关系的资源：先启动服务再创建客户端时，客户端的清理动作可以优先执行。对于会修改全局变量的测试，还是要避免和并行用例同时运行，哪怕最终状态能恢复，也挡不住运行过程中不同用例互相干扰。

并行测试的边界：Setenv 不是可共享配置工具

t.Setenv 的便利来自自动恢复机制，但环境变量本身属于进程级状态。官方文档明确说明，它不能用于并行测试，也不能放在拥有并行祖先的测试里。需要并发覆盖不同配置场景时，更好的方案是把配置作为函数参数、结构体字段或者测试专用依赖传入，而不是靠修改环境变量来切换。

同样的原则也适用于当前工作目录、全局日志级别和包级单例。能作为依赖传入的，就不要在测试里修改全局状态；确实必须修改全局状态的场景，就把这条用例设置为串行运行，并用 Cleanup 明确写好恢复逻辑。

一次完整的检查顺序

1. 为每个用例调用 t.TempDir，不要复用提前写死的固定测试目录。
2. 用 t.Setenv 设置需要的变量，同时确认当前测试以及所有上层父测试都没有标记为并行。
3. 创建服务、文件句柄或者 mock 对象之后，立刻在后面注册 t.Cleanup 做清理。
4. 分别覆盖正常读取、配置缺失和写入失败的几类路径。
5. 用 go test -count=2 ./... 再运行一次全量用例，观察是否还有状态残留的情况。

常见问题

t.TempDir 返回的目录什么时候删除？

它会在当前测试以及它所有的子测试全部完成后自动删除。每次调用都会返回一个全新的独立目录，适合不同的子测试各自准备自己的测试文件。

t.Setenv 可以写在 t.Parallel 后面吗？

不可以。它的作用范围是整个进程，testing 包本身就不允许它用在并行测试或者带有并行祖先的测试中。需要并行运行不同配置的用例时，把配置改成显式传入的依赖会更稳妥。

已经用了 defer，还需要 t.Cleanup 吗？

简单的局部资源用 defer 完全足够，但 t.Cleanup 的生命周期和测试绑定，在子测试、辅助函数和用例提前失败的场景下，更容易保持清理逻辑的一致性。两者不用强行叠加，选离资源创建点更近、逻辑更清晰的方式就行。

让测试自己收好现场

测试隔离的核心不是多写几行删除代码，而是给临时目录、环境变量和额外资源都定义明确的生命周期。先用 t.TempDir 和 t.Setenv 覆盖绝大多数常见场景，再用 t.Cleanup 管控剩下的特殊资源，写出来的测试会更容易重复运行，也很少出现难复现的状态串用问题。