Go testing.TB Cleanup 如何组织临时资源：注册顺序、失败场景与并行测试

测试一旦开始创建临时目录、启动本地服务或占用数据库连接，清理动作就不该藏在测试函数最后几行。Go 的 testing.TB 提供了 Cleanup，可以把资源释放注册在创建点附近；即使后面的断言失败，测试框架也会在当前测试及其子测试结束后执行这些函数。

把“谁创建资源，谁注册清理”作为规则，并记住清理函数按后注册先执行；并行子测试共享资源时，把清理注册在父测试，子测试自己的资源则注册在子测试内部。

资源创建点就是清理责任的起点

很多测试最初只有一个 os.MkdirTemp，后来又加了 HTTP 服务、文件句柄和消息订阅。若把删除目录统一塞进函数尾部，失败断言会让后续代码根本走不到；如果把清理散落在多个 defer 和辅助函数里，读测试的人又很难看出资源归属。

testing.TB 让辅助函数也能接收同一套测试句柄。下面的 helper 创建目录后立即注册删除动作，调用方无需记住“这个目录要不要删”。

func tempWorkspace(t testing.TB) string {
    t.Helper()
    dir := t.TempDir()
    config := filepath.Join(dir, "config.json")
    if err := os.WriteFile(config, []byte(`{"mode":"test"}`), 0o600); err != nil {
        t.Fatalf("write config: %v", err)
    }
    return dir
}

这里直接使用 t.TempDir，因为它已经把目录清理交给了测试框架。如果资源不是 TempDir 自带的，就在创建成功后调用 t.Cleanup 注册释放动作；手工目录的回调里应明确调用 os.RemoveAll，这样清理节点才和资源创建节点一一对应。

Cleanup 的注册顺序决定释放顺序

清理函数不是普通的“测试结束通知”。官方 testing 文档规定，多个回调按后注册先调用，也就是常见的栈式逆序。这个规则适合处理依赖关系：先启动的服务最后关闭，后创建的客户端先断开。

func newFixture(t testing.TB) *Fixture {
    t.Helper()
    server := startServer(t)
    t.Cleanup(func() { server.Close() })

    client := newClient(server.URL)
    t.Cleanup(func() { client.CloseIdleConnections() })
    return &Fixture{Server: server, Client: client}
}

在这个顺序里，客户端清理函数后注册，所以会先执行；服务器关闭函数后执行。若客户端关闭动作依赖服务仍然存在，这个顺序正好符合依赖方向。反过来注册就会得到相反结果，不能只凭“写在前面还是后面”猜测。

失败路径也必须能安全执行

清理函数要允许资源只创建了一半。例如连接建立失败时不要访问一个未初始化的句柄；关闭函数重复调用也最好是幂等的。测试中的清理代码出了 panic，会把原始断言失败变得更难定位。

t.Run 和 t.Parallel 的资源边界

并行测试最容易出错的地方不是 t.Parallel 本身，而是资源到底属于父测试还是子测试。父测试中的 t.Cleanup 会等当前测试及其子测试都完成后才执行，因此它适合清理一组子测试共同使用的服务。

func TestSearch(t *testing.T) {
    server := startServer(t)
    t.Cleanup(func() { server.Close() })

    cases := []struct {
        name string
        path string
    }{
        {"empty", "/search?q="},
        {"keyword", "/search?q=go"},
    }
    for _, tc := range cases {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            response := request(t, server.URL+tc.path)
            if response.StatusCode != http.StatusOK {
                t.Fatalf("status = %d", response.StatusCode)
            }
        })
    }
}

t.Run 不会在并行子测试尚未完成时就让父测试继续结束；因此这里的服务器仍然可用，直到两个子测试都结束。若每个子测试还创建了独立临时文件，应把自己的 Cleanup 注册在子测试回调中，而不是让父测试收集所有路径后统一删除。

哪些写法看似方便，实际会留下隐患

把 Cleanup 当作 goroutine 终止器

t.Cleanup 只会调用你注册的函数，不会自动停止后台 goroutine。启动 goroutine 时仍要提供退出通道或上下文，并在清理函数里先发出停止信号，再等待它退出；否则测试结束后可能还在访问已经删除的临时目录。

父子测试重复释放同一资源

共享服务由父测试创建，就由父测试关闭。子测试只关闭自己创建的客户端或临时文件。重复调用 Close 是否安全取决于具体类型，不能把幂等当成默认行为。

在循环里忘记固定 tc

并行子测试会延迟执行，循环变量如果没有在每轮绑定到新的局部变量，子测试可能读到后续迭代的数据。示例中的 tc := tc 不是清理技巧，却是保证每个子测试请求路径正确的必要边界。

一份可复查的 Cleanup 检查表

遇到测试偶发失败或本地残留文件时，可以按下面的顺序检查：

• 资源是否在创建成功后立刻注册 Cleanup？
• 多个回调的注册顺序是否符合依赖关系？
• 父测试和子测试是否明确区分了共享资源与独占资源？
• 后台 goroutine 是否有停止信号和等待动作？
• 清理失败时是否保留了原始测试错误，而不是产生新的 panic？

相关问题

Cleanup 和 defer 应该怎么选？

只服务于当前函数且不涉及子测试等待时，defer 足够；资源要跨过辅助函数边界、需要覆盖失败路径或要遵守测试/子测试生命周期时，优先用 Cleanup。

Cleanup 会在 Fatal 之后执行吗？

会。Fatal 会结束当前测试函数，但测试框架仍会运行已经注册的清理函数。

并行子测试能清理父测试创建的服务吗？

不建议。父测试负责共享服务的生命周期，子测试只释放自己创建的资源，避免一个子测试提前关闭仍被其他子测试使用的对象。

把资源生命周期写进测试结构

好的测试不需要读者在文件末尾寻找一串“可能漏掉的清理动作”。让资源创建、使用和清理在同一个作用域附近出现，再利用 Cleanup 的失败保障、逆序规则和 t.Run 的等待边界，测试失败时留下的现场会更可解释，并行测试也不必靠运气通过。