Go 测试资源怎么自动清理：t.Cleanup 注册时机与并行测试边界

测试用例明明失败了，临时目录却留在磁盘上；更麻烦的是，几个子测试共用环境变量时，清理顺序一变，后面的用例就开始随机失败。Go 的 testing.T.Cleanup 正好解决这类“测试结束了但资源没收口”的问题，不过它不是把 defer 换个名字：注册时机、执行顺序和 t.Parallel 的边界，都会影响最终结果。

先看一个会污染后续用例的测试

假设测试需要临时切换 APP_MODE，并在临时目录里写一个配置文件。只在成功路径手动恢复环境变量，失败时就会留下污染；如果把恢复代码塞进某个分支，断言提前失败也会绕开它。

func TestLoadConfig(t *testing.T) {
    oldMode := os.Getenv("APP_MODE")
    os.Setenv("APP_MODE", "test")
    dir := t.TempDir()
    if err := os.WriteFile(filepath.Join(dir, "app.yaml"), []byte("port: 8080"), 0600); err != nil {
        t.Fatal(err)
    }
    if got := loadMode(); got != "test" {
        t.Fatalf("mode = %q", got)
    }
    os.Setenv("APP_MODE", oldMode)
}

t.TempDir 本身会由 testing 框架清理，但环境变量、注册表、临时 mock 或自建连接仍需要明确收口。这里真正要修的不是多写一行删除目录，而是让清理动作绑定到测试生命周期。

defer、t.Cleanup 和 TestMain 怎么选

这三个入口都能做收尾，但作用范围不一样。别为了统一风格把所有释放动作都搬到 TestMain，全局钩子越大，测试之间越容易互相影响。

把清理注册放在资源创建之后

最稳的顺序是“创建一个资源，立刻注册它的清理函数”，这样中途任意一步失败，都不会让已经创建的资源失去负责人。下面的辅助函数把环境变量恢复封装起来：

func setEnvForTest(t *testing.T, key, value string) {
    t.Helper()
    old, existed := os.LookupEnv(key)
    if err := os.Setenv(key, value); err != nil {
        t.Fatalf("set %s: %v", key, err)
    }
    t.Cleanup(func() {
        if existed {
            if err := os.Setenv(key, old); err != nil { t.Errorf("restore %s: %v", key, err) }
        } else if err := os.Unsetenv(key); err != nil { t.Errorf("restore %s: %v", key, err) }
    })
}

调用方不必保存旧值，也不必在每个断言前后插入恢复逻辑：

func TestMode(t *testing.T) {
    setEnvForTest(t, "APP_MODE", "test")
    if got := loadMode(); got != "test" { t.Fatalf("loadMode() = %q", got) }
}

验收时把断言故意改成失败，再运行同包的其他测试，下一条测试仍应读到原来的 APP_MODE。如果环境变量没有恢复，问题通常出在 helper 没有拿到当前测试的 t，或调用方又在外层覆盖了它。

多次 Cleanup 为什么要按反向顺序执行

同一测试注册多个清理函数时，testing 会按后进先出执行。这和连续写多个 defer 的规则一致：后创建的依赖应先释放。

func TestResourceOrder(t *testing.T) {
    db := openTestDB(t)
    t.Cleanup(func() { db.Close() })
    tx := beginTestTx(t, db)
    t.Cleanup(func() { tx.Rollback() })
}

执行时先回滚事务，再关闭数据库连接。这里别只看最终 PASS，还要确认清理日志顺序符合依赖关系；否则下一次扩展 helper 时，很容易出现连接已关闭的二次错误。

子测试与 t.Parallel 的边界要分开看

父测试注册的 t.Cleanup 不会在子测试刚返回时立刻执行，而是在父测试及其子测试都结束后执行。因此，父测试可以准备一份供子测试使用的只读资源；但一旦子测试调用 t.Parallel，父测试后续代码和共享可变状态就不应再修改。

func TestProfiles(t *testing.T) {
    setEnvForTest(t, "APP_MODE", "test")
    profiles := loadProfiles(t)
    for _, name := range []string{"basic", "admin"} {
        name := name
        t.Run(name, func(t *testing.T) {
            t.Parallel()
            if _, ok := profiles[name]; !ok { t.Fatalf("profile %q missing", name) }
        })
    }
}

常见误区是把清理动作写进父测试循环，或者在并行子测试里修改同一个 map、环境变量和全局 mock。Cleanup 能保证生命周期收口，却不能替你解决数据竞争；需要写入时，为每个子测试创建独立副本，或去掉并行。

用一组小验收确认清理真的生效

不要只看测试输出为 PASS。可以把检查拆成三件事：失败路径是否清理、子测试结束时机是否符合预期、并行执行时是否有共享写入。

1. 让一次断言故意失败，再运行同包的其他测试，确认环境变量和 mock 状态没有泄漏。
2. 用带日志的 cleanup 函数确认子测试结束后父资源才释放，日志顺序应与注册顺序相反。
3. 执行 go test -race ./...，重点检查 t.Parallel 子测试访问的 map、全局变量和文件。
4. 对资源 helper 做一次重复调用，确认每次调用都注册独立的恢复动作，不依赖全局旧值。

go test ./... -count=1
go test -race ./...

常见问题

t.Cleanup 会在 t.Fatal 后执行吗？

会。t.Fatal 结束当前测试函数后，testing 仍会执行已经注册的 cleanup。前提是资源创建后确实注册成功。

Cleanup 和 defer 哪个更快？

通常不应按速度选择。defer 绑定当前函数，Cleanup 绑定测试生命周期；测试资源优先保证隔离和失败路径可收口。

并行测试能共享父测试创建的临时目录吗？

可以共享只读内容，但不要让多个并行子测试写同一文件或修改同一全局状态。需要写入时，为每个子测试创建独立目录或副本。

什么时候应该使用 TestMain？

只有当资源确实属于整个测试进程，例如统一启动一次的本地服务或测试数据库连接池，才考虑 TestMain。单个用例的资源放在 t.Cleanup 更容易隔离。

把清理责任放回创建资源的测试

t.Cleanup 的价值不在于少写几行代码，而在于把“谁创建、谁负责释放”固定到测试边界。资源创建后立即注册清理函数，依赖资源按创建顺序登记，子测试只读共享数据并用 -race 验收，临时目录、环境变量和 mock 状态就不容易跨用例泄漏。