Go testing.T.Cleanup 注册顺序怎么执行：嵌套测试、资源释放与失败场景

测试代码里最容易被忽略的不是断言，而是收尾顺序：父测试先准备一个临时目录，子测试又创建连接，最后到底谁先释放？testing.T.Cleanup 的规则很明确——同一个测试中后注册的清理函数先执行；父测试的清理函数则要等该测试及其所有子测试结束后才执行。

把“谁创建、谁清理”放在同一个测试作用域里，并按依赖的反方向注册 t.Cleanup，就能让嵌套测试在成功、失败和提前退出时都保持可预期。

先记住 Cleanup 的两个边界

t.Cleanup 注册的函数不会在注册点立刻运行，而是在当前测试（或子测试）以及它的子测试完成后执行。官方 testing 文档还明确规定，多个清理函数采用后注册先调用的顺序，这和栈式资源管理是一致的。

因此，下面的顺序是确定的：准备A、准备B、测试主体、释放B、释放A。如果 准备B 依赖 准备A，这种反向释放正好保护了依赖关系。

func TestCleanupOrder(t *testing.T) {
    t.Cleanup(func() { t.Log("释放A") })
    t.Cleanup(func() { t.Log("释放B") })
    t.Log("测试主体")
}

这张图只保留真实调用关系：t.Cleanup 注册两个动作，测试主体结束后按栈顶到底部执行。

嵌套 t.Run 时，父清理为什么在最后

父测试调用 t.Run 后，子测试拥有自己的 *testing.T 和自己的清理栈。子测试返回后，子测试注册的清理函数先完成；只有父测试和它的所有子测试都结束，父测试注册的清理函数才会运行。

func TestNestedCleanup(t *testing.T) {
    t.Cleanup(func() { t.Log("释放父资源") })

    t.Run("child", func(t *testing.T) {
        t.Cleanup(func() { t.Log("释放子资源") })
        t.Log("子测试主体")
    })
}

这意味着父测试可以先准备子测试需要的共享前置条件，但不要把子测试独占的连接、文件或临时状态交给父清理函数兜底。把清理注册在创建资源的那个 *testing.T 上，作用域更清楚，也不容易和并行子测试互相踩到。

失败、Fatal 和 Skip 会不会跳过 Cleanup

不会把它当成普通的函数尾部代码。测试因为 t.Fatal、t.Skip 或失败标记离开主体后，测试框架仍会进入已经注册的清理阶段。清理函数本身如果再次调用 Fatal，反而会让真正的资源错误和原始断言失败混在一起，所以收尾函数更适合记录状态、关闭资源并用普通日志保留线索。

常见误用：用 defer 代替嵌套测试的 Cleanup

在没有子测试、没有并行生命周期时，函数体内的 defer 当然仍然有价值。但它绑定的是当前 goroutine 的函数返回，不表达“等待所有子测试完成”这一测试框架语义。尤其是资源由父测试创建、子测试使用的场景，单纯依赖 defer 容易让代码读者误判释放时机。

另一个误区是把一个可变全局对象注册到多个测试的清理函数里。测试顺序一变，清理动作就可能重复。更稳的方式是让每个测试拥有自己的资源，或用明确的所有权函数返回一个只关闭一次的对象。

写完 Cleanup 后的四项检查

• 资源是否由创建它的同一个测试作用域注册清理？
• 后注册的资源是否会先释放，依赖关系是否与此相符？
• 父清理是否确实允许等待全部 t.Run 子测试结束？
• 清理函数是否避免用 Fatal 覆盖原始测试线索？

相关问题

多个 t.Cleanup 的执行顺序固定吗？

固定。同一个测试对象上按后注册先执行，也就是 LIFO 顺序。

子测试能使用父测试注册的资源吗？

可以，但父资源必须一直存活到所有子测试结束；父测试的 Cleanup 正是最后一道释放边界。

Cleanup 里还能读取测试状态吗？

可以记录日志和检查收尾状态，但不要把清理函数写成第二个测试主体，也不要依赖不稳定的测试执行顺序。

小结

testing.T.Cleanup 的核心不是“比 defer 更方便”，而是它把资源释放纳入测试树的生命周期：同一作用域后注册先执行，父测试在所有子测试结束后收尾。按资源依赖倒序注册，并让资源所有权和 *testing.T 作用域对应，测试失败时也能留下干净、可解释的收尾行为。