Go testing.TB.Cleanup 怎么管理测试资源：注册时机、执行顺序与失败排查

测试里最容易留下脏状态的地方，通常不是断言，而是断言失败之后没有恢复的临时目录、环境变量和后台服务。testing.TB.Cleanup 提供了一条很直接的收尾路径：在测试或辅助函数里注册清理函数，测试返回后由测试框架自动调用。

把资源的创建和清理放在同一个辅助函数里，并在资源创建成功后立刻注册 Cleanup，通常就能同时解决异常退出、子测试隔离和清理顺序三个问题。

先用一个辅助函数收好临时目录

最小可用的写法是让辅助函数返回目录路径，同时把删除动作封装在它内部。这样调用方只关心目录能否使用，不必在每个测试分支里重复写删除逻辑。

func tempWorkspace(t testing.TB) string {
    t.Helper()

    dir := t.TempDir()
    marker := filepath.Join(dir, "input.txt")
    if err := os.WriteFile(marker, []byte("ready"), 0600); err != nil {
        t.Fatalf("write fixture: %v", err)
    }
    return dir
}

func TestReadConfig(t *testing.T) {
    dir := tempWorkspace(t)
    // 测试只使用 dir；临时目录由测试框架统一回收。
    _ = dir
}

这里使用的是 t.TempDir，它本身已经注册了目录清理。这个例子仍然值得保留，因为自定义资源也应遵循同样的结构：资源成功创建后，马上注册对应的 Cleanup。

在资源创建点绑定 Cleanup

当资源不是 TempDir 这类标准设施时，清理函数应该和创建代码挨在一起。下面以环境变量为例，重点不在测试什么业务，而在恢复旧值和处理原本不存在的情况。

func setTestMode(t testing.TB, value string) {
    t.Helper()

    old, existed := os.LookupEnv("APP_MODE")
    if err := os.Setenv("APP_MODE", value); err != nil {
        t.Fatalf("set APP_MODE: %v", err)
    }
    t.Cleanup(func() {
        var err error
        if existed {
            err = os.Setenv("APP_MODE", old)
        } else {
            err = os.Unsetenv("APP_MODE")
        }
        if err != nil {
            t.Errorf("restore APP_MODE: %v", err)
        }
    })
}

清理函数里适合使用 t.Errorf 报告恢复失败，不要再用会直接终止当前测试流程的方式。若清理动作本身依赖一个仍然有效的资源，应让它后注册，利用后进先出的顺序先释放依赖者。

用注册顺序表达资源依赖

Cleanup 的顺序不是随机的。同一测试中先注册的函数后执行，后注册的函数先执行。可以把它看成一摞盘子：最后放上的那只，最先拿走。

func TestCleanupOrder(t *testing.T) {
    t.Cleanup(func() { t.Log("close client") })
    t.Cleanup(func() { t.Log("close server") })
}

// 输出顺序：close server、close client

如果客户端还依赖服务端，就应该先注册客户端清理，再注册服务端清理。测试完成时，服务端会在客户端之后关闭。这个规则比在测试末尾手写一长段反向释放代码更不容易被新增分支破坏。

子测试的边界和父测试的收尾

每个 t.Run 都有自己的测试上下文。子测试注册的 Cleanup 会在该子测试返回后运行；父测试注册的 Cleanup 则等所有子测试完成后再运行。共享夹具如果在父层创建，就不要让子测试提前把它关掉。

func TestGroups(t *testing.T) {
    client := newTestClient(t)
    t.Run("valid", func(t *testing.T) {
        t.Cleanup(func() { t.Log("remove child fixture") })
        _ = client
    })
    t.Cleanup(func() { t.Log("close shared client") })
}

这里有一个容易忽略的细节：父测试的 Cleanup 在代码中可以晚于 t.Run 注册，但它仍然属于父测试层级。为了让依赖关系更清楚，建议在创建父级资源后立即注册清理，再启动子测试。

流水线式排查清理失败

遇到测试之间互相污染时，可以按四个点排查：先看资源是否在创建成功后注册；再看清理函数是否修改了共享状态；接着确认子测试没有越界释放父级资源；最后检查清理函数中的错误是否被日志或断言吞掉。

常见误区是把 Cleanup 当成普通的 defer。它们都能表达收尾，但 Cleanup 绑定的是测试上下文，能自然覆盖辅助函数返回、子测试边界和测试失败场景；资源只在测试函数内部短暂存在时，defer 依然足够，别为了形式统一而强行改写。

常见问题与延伸问答

Cleanup 里还能调用测试对象的方法吗？

可以，测试框架会在清理阶段执行已注册函数，常见做法是用 Log 或 Errorf 记录收尾问题。清理代码要保持短小，避免再创建需要清理的新资源。

多个 Cleanup 为什么要反着执行？

后进先出能自然匹配资源依赖：后创建的客户端先关闭，先创建的底层服务最后关闭。只要注册顺序跟创建顺序一致，释放顺序通常就正确。

父测试能替子测试清理资源吗？

父测试可以清理父层级创建的共享资源，但子测试自己的临时状态应由子测试或子测试辅助函数负责。把所有清理集中到父层级，会让失败定位和资源边界变得模糊。

把规则收敛成一条可执行习惯

以后写测试辅助函数时，可以固定采用“创建资源、确认成功、立即注册 Cleanup、返回句柄”的顺序。临时目录和环境变量先用标准库能力；客户端、服务端、数据库夹具等自定义资源，再用注册顺序表达依赖。这样即使测试中途失败，下一条测试也能从干净状态开始。