Go testing.TB.Cleanup 怎样让临时资源按测试结束释放

在创建临时资源成功后调用 tb.Cleanup(func() { ... })，就能把释放动作绑定到传入的测试对象。辅助函数返回不会触发它；该测试及其全部子测试完成后才执行清理。同一个测试登记的清理函数按后登记先执行的顺序调用。

官方地址：https://go.dev/

当测试从几个扩展到几百个，资源泄漏经常来自归属不清：创建函数负责打开，调用者忘记关闭；或者辅助函数用defer关闭，返回的句柄已失效。本文以临时文件为例，把创建与登记放在一起，再说明父子测试的边界。示例是可供项目采用的原创代码，不是已有服务的上线测量报告。

用例增多时先明确资源归属

先决定资源服务哪一个测试。每个子用例独立的数据，应把子测试的t传给辅助函数；所有子用例共享的只读输入，可以由父测试创建，并把清理登记到父测试。Cleanup并不会自动推断资源属于谁，它只认识接收调用的测试对象。

Cleanup没有返回值，也不接收error类型的函数。需要检查释放错误时，在闭包里调用Errorf报告；不要把Close函数的错误悄悄丢掉。

把释放动作交给测试对象

在现有Go模块中保存fixture_test.go。辅助函数接受testing.TB，便于测试和基准测试共用；它不是让业务对象依赖testing包的理由，应留在测试代码中。

package fixture

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

func openFixture(tb testing.TB) *os.File {
    tb.Helper() // 把辅助函数中的错误定位到调用处。
    dir := tb.TempDir()
    f, err := os.Create(filepath.Join(dir, "payload.txt"))
    if err != nil {
        tb.Fatalf("创建测试文件: %v", err)
    }
    // 创建成功就登记关闭；辅助函数返回后，文件仍可使用。
    tb.Cleanup(func() {
        if err := f.Close(); err != nil {
            tb.Errorf("关闭测试文件: %v", err)
        }
    })
    return f
}

func TestFixture(t *testing.T) {
    f := openFixture(t)
    if _, err := f.WriteString("sample-data"); err != nil {
        t.Fatalf("写入测试文件: %v", err)
    }
    info, err := f.Stat()
    if err != nil {
        t.Fatalf("读取文件属性: %v", err)
    }
    if info.Size() != int64(len("sample-data")) {
        t.Errorf("大小不符: %d", info.Size())
    }
    // 此处不再手动Close，关闭所有权已交给本测试的Cleanup。
}

文件一旦创建成功便登记关闭，即使后续断言通过Fatal提前结束测试，清理仍有机会按测试生命周期执行。不要在openFixture内部另写defer f.Close，否则返回后第一次写入就可能遇到文件已关闭。

这里使用TempDir管理目录，不再重复登记RemoveAll。TempDir先调用，文件关闭后登记；对这个示例，文件关闭会先于同一测试中之前登记的目录清理，避免仍有打开句柄时删除目录。

父测试资源如何覆盖并行子测试

以下测试放在同一个文件，复用上面的导入和辅助函数。父测试创建只读输入，子测试各自读取，资源的范围由父测试t决定。

func TestSharedInput(t *testing.T) {
    f := openFixture(t) // 由父测试持有，共享内容在并行读取前准备好。
    if _, err := f.WriteString("read-only-input"); err != nil {
        t.Fatal(err)
    }
    path := f.Name()
    for _, name := range []string{"alpha", "beta"} {
        t.Run(name, func(t *testing.T) {
            t.Parallel()
            // 子测试各自打开文件，不共享文件游标，也不修改同一份内容。
            data, err := os.ReadFile(path)
            if err != nil {
                t.Fatal(err)
            }
            if string(data) != "read-only-input" {
                t.Errorf("内容不符: %q", data)
            }
        })
    }
    // 父测试的Cleanup等所有子测试完成后才关闭文件、删除临时目录。
}

使用t.Parallel的子测试可能在父测试函数返回后才继续执行。父函数里的defer只服从函数返回时机，因此不适合作为这类共享输入的删除位置。父测试Cleanup则等待子测试完成，能表达所需的作用域。

生命周期正确不等于并发安全。若子测试会写文件，应给它们各自创建资源，或明确使用同步机制；不要把同一个文件游标当作互不干扰的输入。也不要在父测试中等待一组已调用Parallel、尚待父函数返回的子测试，避免互相等待。

按依赖关系注册清理动作

把清理当作依赖关系的反向拆卸：先建立底层资源，再建立依赖它的对象；清理登记紧跟各自创建成功的位置。依赖者后登记，结束时先释放。例如文件先创建、缓冲写入器后创建，便应先刷新缓冲，再关闭文件。这个规则只描述同一个测试对象登记的清理序列，不应拿来推断不同测试之间的全局顺序。

每个资源只指定一个关闭责任方。本例已经交给Cleanup，就不要在正文断言末尾再Close一次，否则重复关闭可能导致清理阶段报错。确实需要测试“关闭后的行为”时，应让被测代码拥有关闭动作，另用能识别状态的清理封装兜底，不能简单忽略所有Close错误。

后台任务也要有明确退出协议。Cleanup不会替你停止任意goroutine；需要取消信号和完成通知时，应在清理闭包中先请求停止，再等待任务在有限时间内退出，最后释放它依赖的资源。

把清理失败变成可定位信号

# 在已有模块的目录运行；-v显示测试名称与清理阶段的日志。
go test -v -run "TestFixture|TestSharedInput" .

预期两个测试及其子测试通过，未发生写入已关闭文件的错误；如果关闭失败，Errorf会让对应测试留下失败信息。这里描述预期结果，没有声称已在本机执行。迁移更多辅助函数时，可关注清理错误所属测试名、文件句柄是否集中由单一位置关闭，以及共享资源是否被提前删除，不能虚构资源使用量下降百分比。

Cleanup遇到Fatal就一定不执行吗？

Fatal结束当前测试的正常执行，但不等于正常测试清理被跳过。进程被强制终止、直接os.Exit或外部超时杀死时，不能依赖Cleanup完成持久化或关键业务补偿。

只需要临时目录，还要再写Cleanup吗？

通常不需要重复删除，TempDir已自动安排目录移除。目录里的额外打开句柄仍需由资源拥有者关闭。

能把清理登记到另一个测试t吗？

应传入实际拥有资源的测试对象，避免将子测试资源意外延长到父测试结束，也不要在测试生命周期结束后继续登记。测试资源的范围越明确，失败位置越容易定位。

后续扩展资源辅助库时，保留“创建成功立即登记、使用者不重复关闭、共享范围跟随父子测试”的约定。它解决的是释放责任与测试作用域，资源是否可并行访问仍需单独设计。

官方资料：testing.Cleanup与相关方法。