Go 测试注册多个 t.Cleanup 时怎么安排资源释放顺序

Go 测试注册多个 t.Cleanup 时，应按“底层资源先获取并先登记，依赖它的资源后获取并后登记”来安排。属于同一个测试的清理函数按后注册先调用执行；触发条件是该测试以及它的全部子测试完成，而不是辅助函数刚刚返回。

例如文件句柄依赖临时目录，就先登记目录移除，再登记文件关闭。释放时文件关闭排在目录移除前面。若资源要供并行子测试共享，则把清理登记在父测试的 t 上。

官方地址：https://pkg.go.dev/testing#T.Cleanup

把资源依赖写成反向释放约定

设想一个测试需要建立临时目录、创建文件，再交给被测逻辑写入内容。只有“所有资源最后都能清理”还不够：如果目录移除排在文件关闭之前，不同系统对打开文件的处理可能不同，故障也就更难解释。测试夹具需要明确依赖关系，而不是靠文件系统恰好允许某种操作。

可以把这种组织方式称为“获取即登记，按依赖反向释放”。它没有引入额外框架，只是利用 Cleanup 的后进先出规则，把资源所有权放在获取资源的位置。依赖链越清楚，登记顺序就越容易决定。

上图表达的是文件依赖目录、清理动作归属测试的静态关系。真正的调用顺序由正文规则决定，不需要把图当成执行轨迹。如果两个资源互不依赖，不必人为制造先后关系；如果一个资源的关闭需要另一个资源仍可用，就应让前者的清理后登记。

为什么父测试共享资源容易提前关闭

问题在并行子测试中更容易暴露。父测试函数里调用 t.Run，子测试调用 t.Parallel 后可能暂停，等父测试函数返回后再继续。父函数上的 defer 会在函数返回时执行，因此“在父函数末尾关闭共享资源”可能发生在并行子测试真正使用资源之前。

这里必须区分函数返回和测试完成。父测试函数返回，并不代表它的所有子测试都完成。父级 Cleanup 绑定的是测试生命周期，能够覆盖这些子测试；父函数 defer 绑定的是函数调用生命周期，不能承担同样的职责。

这也不是所有测试都应统一改用 Cleanup 的理由。若某个文件只在一个辅助函数内部使用，函数返回前就应关闭，那么 defer 仍然直接。判断标准是资源的最后使用者在哪一层，而不是哪种写法更短。

获取成功后立即登记释放动作

下面是一份完整的原创测试示例，可保存为 cleanup_order_test.go。辅助函数取得资源后立即登记清理，返回文件句柄给测试使用。示例只展示所有权和错误处理，不依赖数据库、网络或第三方测试库。

package cleanuporder

import (
    "os"
    "path/filepath"
    "testing"
)

func openFixture(t *testing.T) *os.File {
    t.Helper()
    dir, err := os.MkdirTemp("", "cleanup-fixture-")
    if err != nil {
        t.Fatal(err)
    }
    // 底层目录先取得、先登记，所以它最后释放。
    t.Cleanup(func() {
        if err := os.RemoveAll(dir); err != nil {
            t.Errorf("移除测试目录失败: %v", err)
        }
    })
    f, err := os.Create(filepath.Join(dir, "payload.txt"))
    if err != nil {
        t.Fatal(err) // 已登记的目录清理仍然有效。
    }
    // 文件依赖目录；后登记关闭，使其在目录移除前调用。
    t.Cleanup(func() {
        if err := f.Close(); err != nil {
            t.Errorf("关闭测试文件失败: %v", err)
        }
    })
    return f
}

func TestFixture(t *testing.T) {
    f := openFixture(t)
    // 辅助函数返回不会触发绑定在当前测试上的 Cleanup。
    if _, err := f.WriteString("fixture-data"); err != nil {
        t.Fatal(err)
    }
}

目录创建失败时没有目录资源可释放，直接终止测试即可。文件创建失败时，目录的清理早已登记，不必在失败分支再复制一份删除代码。文件创建成功后再登记 Close，避免对无效句柄安排关闭操作。

这里把清理失败报告为 t.Errorf，让失败可见，同时不主动终止当前清理函数之外的诊断。示例没有同时安排 defer Close，也没有在测试正文再次关闭文件；否则可能引入重复关闭错误，反而掩盖真正的释放问题。

按代码中的登记关系，正常结束时会先调用文件关闭，再调用目录移除。这个顺序来自 Cleanup 的契约，示例不声称已经运行，也没有虚构测试输出。

defer 和 Cleanup 分别属于哪个作用域

一个常见反例是辅助函数创建文件，写下 defer f.Close()，然后把 f 返回给测试。调用方拿到的可能已经是关闭后的句柄。把清理登记在传入的 t 上，才能让释放边界覆盖调用方的使用期。

另一个反例是子测试获取自己的临时资源，却捕获外层父测试的 t 来登记清理。这样虽然通常不至于立刻关闭，但资源会一直保留到父测试完成。大量子测试可能因此同时积累文件或连接。给辅助函数传当前子测试的 t，才能缩短局部资源的占用期。

并行子测试需要独立资源还是共享资源

以下片段使用前面同一测试文件中的导入。目录归父测试所有，每个子测试写不同文件。t.TempDir 本身就安排了测试结束后的目录清理，不需要再给同一目录登记一份 RemoveAll。

func TestSharedDirectory(t *testing.T) {
    dir := t.TempDir() // 父测试拥有目录，其清理覆盖所有子测试。
    for _, name := range []string{"alpha", "beta"} {
        name := name // 明确固定当前子测试使用的文件名。
        t.Run(name, func(t *testing.T) {
            t.Parallel()
            // 每个子测试只写自己的文件，避免同一路径竞争。
            path := filepath.Join(dir, name+".txt")
            if err := os.WriteFile(path, []byte(name), 0600); err != nil {
                t.Fatal(err)
            }
        })
    }
}

共享目录并不等于共享同一个可变对象。若多个并行子测试操作同一个文件句柄、同一条事务或同一张状态表，Cleanup 的顺序规则不会自动消除竞争。要么拆成独立夹具，要么给并发访问建立明确的同步与隔离机制。

还要避免从兄弟子测试的清理中推导固定顺序。后进先出的比较范围是同一个测试对象上的登记集合；并行兄弟之间没有可供业务依赖的固定清理次序。需要统一释放共享服务时，应由父测试持有服务，而不是让某个子测试负责“最后关闭”。

改造测试辅助函数前的判断清单

• 先画出资源依赖：关闭某个对象时，还需要哪些对象存在？
• 取得资源后立刻登记，登记必须放在成功分支之后。
• 共享资源使用父测试的 t，局部资源使用当前子测试的 t。
• 同一资源指定一个释放负责人，避免 defer、Cleanup 和正文同时关闭。
• 清理函数需要自行结束；Cleanup 不能替代停止后台任务、等待退出或处理阻塞。

这个约定的代价是清理动作分散在资源获取处，阅读者需要结合依赖理解调用顺序。对于紧密耦合、必须一起收尾的一组对象，也可以用一个 Cleanup 显式组织它们的关闭逻辑；此时应分别处理每个错误，避免前一个失败导致后面的资源被遗漏。

辅助函数调用 Fatal 后，已经登记的 Cleanup 还会执行吗？

正常 testing 生命周期中会。示例把目录清理放在文件创建之前登记，正是为了覆盖后续创建失败而终止测试的情况。进程被强制退出等情况不属于这个保证。

所有子测试都完成后，还需要手工调用清理函数吗？

无需再调用已交给 Cleanup 管理的同一释放动作。若资源必须在测试中途释放，应另外设计清晰的所有权或幂等关闭接口，不要让两条路径无约束地重复关闭。

可以把所有清理都登记到父测试吗？

可以延长它们的生命周期，但往往没有必要。只有确实被多个子测试共用的资源才需要父级所有权；局部资源归局部测试，有助于降低资源峰值并使失败定位更直接。

参考：Go testing：Cleanup 的生命周期与登记顺序；Go testing：子测试与并行行为。这些官方约定支持上述安排，代码示例为本文原创。