Go testing.B.Cleanup怎样回收基准测试资源怎样避免临时目录残留

如果基准测试会创建临时目录、打开文件或启动辅助资源，最稳妥的做法是：准备资源后立即调用 b.Cleanup 注册释放函数，再调用 b.ResetTimer 开始正式计时。Cleanup 函数会在当前基准结束后执行，而不是每次 b.N 迭代执行一次。

先记住三个边界

testing.B.Cleanup 适合绑定“当前基准生命周期”的资源。它有三个容易混淆的边界：

• 注册动作发生在准备阶段，通常放在创建资源之后、b.ResetTimer 之前。
• 清理动作发生在基准函数返回、框架结束该基准之后，不会在每次迭代结束时触发。
• 多个 Cleanup 按后注册先执行的顺序调用，因此依赖关系复杂时要先注册底层资源的清理。

因此，Cleanup 解决的是“测试结束后不要遗留资源”，并不负责把每轮迭代恢复到初始状态。如果每次迭代都要重置输入，应在循环中显式完成，或把每个样本拆成独立的子基准。

用 b.Cleanup 回收自定义临时资源

当资源不是测试框架自动创建的，例如临时目录里还要放配置文件、索引文件或外部工具输入，可以用 os.MkdirTemp 创建目录，再把 os.RemoveAll 注册给 Cleanup：

package bench

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

func BenchmarkLoadConfig(b *testing.B) {
    // 准备阶段创建一次目录，目录生命周期覆盖整个基准。
    dir, err := os.MkdirTemp("", "bench-config-")
    if err != nil {
        b.Fatal(err)
    }
    // 无论基准正常结束还是提前失败，都在结束后删除目录。
    b.Cleanup(func() {
        if err := os.RemoveAll(dir); err != nil {
            b.Errorf("清理临时目录失败: %v", err)
        }
    })

    configPath := filepath.Join(dir, "config.txt")
    // 把一次性输入准备放在计时区间外，避免把 I/O 准备算进结果。
    if err := os.WriteFile(configPath, []byte("mode=fast\n"), 0o600); err != nil {
        b.Fatal(err)
    }
    b.ResetTimer()

    for i := 0; i 

这里的目录只创建一次，Cleanup 也只注册一次。基准循环读取的是同一个文件，适合测量读取路径本身；如果要测量“每次创建并删除目录”的成本，就不能把创建和删除放在 Cleanup 中代替循环操作，而应明确把它们写进计时区间。

为什么要在 ResetTimer 前注册清理

b.ResetTimer 会重新开始计时并清零已经累计的时间、迭代次数和分配统计。把资源准备放在它前面，可以让结果集中反映被测逻辑；但 Cleanup 仍然属于基准生命周期的一部分，最终会在基准结束时执行。

func BenchmarkDecode(b *testing.B) {
    // 只做一次输入构造，避免每次迭代都重新分配样本。
    input := make([]byte, 4096)
    b.Cleanup(func() {
        // 这里可释放与整个基准绑定的外部句柄或临时资源。
        input = nil
    })
    b.ResetTimer()

    for i := 0; i 

不要把 Cleanup 当作每次循环的 defer。若被测代码需要每轮拥有独立对象，应在循环里创建并释放，或者使用子基准隔离每组样本；Cleanup 只适合当前 BenchmarkDecode 这一生命周期。

b.Cleanup 和 b.TempDir 怎么选

如果只是临时目录，优先考虑 b.TempDir；如果目录之外还有需要关闭的资源，可以同时使用 b.TempDir 和 b.Cleanup，但不要对同一个资源重复删除或关闭。

运行基准并判断清理是否合理

# 只运行名称匹配的基准，并显示内存分配统计。
go test -run '^$' -bench '^BenchmarkLoadConfig$' -benchmem ./...

# 需要观察多轮结果时，重复执行并比较 ns/op 与 allocs/op。
go test -run '^$' -bench '^BenchmarkLoadConfig$' -benchmem -count=5 ./...

命令输出中的 ns/op 和 allocs/op 主要对应计时区间内的代码。Cleanup 的删除动作发生在基准完成后，不应把它误读为每次迭代的成本。若清理失败，示例通过 b.Errorf 报告错误；对于无法继续的准备错误，则用 b.Fatal 立即结束当前基准。

常见问题

Cleanup 会在每次 b.N 迭代后执行吗？

不会。它绑定的是当前测试或基准的结束阶段；需要逐轮清理时必须在循环中显式处理。

Cleanup 应该放在 ResetTimer 后面吗？

通常不应这样安排。资源创建完成后立即注册 Cleanup，再调用 ResetTimer，可以避免遗漏清理，也不会把准备动作纳入计时。

清理函数注册多个时按什么顺序执行？

按后注册先执行。依赖其他资源的清理函数可以先注册，让底层资源在后面释放。

临时目录应该用 Cleanup 还是 TempDir？

只有临时目录时优先用 b.TempDir；需要组合关闭句柄、删除文件或通知外部资源时，再用 b.Cleanup 补充自定义释放逻辑。

总结：先准备资源，再注册 b.Cleanup，然后用 b.ResetTimer 划定计时区间。记住 Cleanup 是“基准结束后的统一回收”，不是“每轮迭代的状态重置”，基准结果和资源生命周期就不会混在一起。