Go testing.T.Cleanup 注册多个清理函数时顺序是什么

Go 的 testing.T.Cleanup 不是“注册几个就按几个的顺序执行”。同一个测试对象上，清理函数遵循后注册先调用的 LIFO 规则；而且它会等当前测试及其子测试完成后才进入清理阶段。要安排有依赖的资源释放，先把依赖关系画出来，再决定注册顺序。

多个 t.Cleanup 为什么是后注册先执行

官方 testing 文档把规则写得很明确：Cleanup 注册的函数会在测试以及它的子测试完成后调用，并按“最后添加、最先调用”的顺序执行。可以把同一个 T 上的回调理解成一摞清理卡片：后放上去的卡片先取走。

因此，若上层资源依赖底层资源，通常先注册上层资源的释放，再注册底层资源的释放。这样后注册的底层释放会先执行，反而可能不符合依赖；更稳妥的做法是让“需要先释放”的回调最后注册，并在代码中用注释写清原因。

下面这个例子把两个回调挂在子测试上，再由父测试读取记录。代码中的注释专门标出注册顺序，避免把它和 defer 的阅读习惯混在一起。

package cleanup_test

import (
    "reflect"
    "testing"
)

func TestCleanupOrder(t *testing.T) {
    var events []string

    t.Run("case", func(t *testing.T) {
        t.Cleanup(func() {
            // 先注册的回调最后执行，适合较晚释放底层依赖。
            events = append(events, "first")
        })
        t.Cleanup(func() {
            // 后注册的回调先执行，适合先释放上层资源。
            events = append(events, "second")
        })
    })

    // 子测试返回后，它的两个 Cleanup 已完成，父测试可以读取完整记录。
    want := []string{"second", "first"}
    if !reflect.DeepEqual(events, want) {
        t.Fatalf("cleanup order = %v, want %v", events, want)
    }
}

这里的断言放在 t.Run 返回之后，是因为子测试的清理阶段属于子测试生命周期。若在子测试内部就读取 events，你看到的仍可能是不完整状态。

子测试结束后，父测试还能看到什么

t.Run 会创建新的测试对象。子测试注册的 Cleanup 在子测试及其子孙测试完成后执行；父测试注册的 Cleanup 则属于父测试自己的生命周期，不能把二者当成一条共享回调队列。共享切片、临时目录或测试客户端时，尤其要先确认资源到底挂在哪个 T 上。

一个常见安排是：子测试负责创建并关闭只属于自己的资源，父测试负责共享夹具的最终收尾。若父级清理需要读取子测试写入的状态，应让读取动作发生在子测试返回之后，同时保证父级清理没有提前关闭该状态所依赖的对象。

资源依赖、并发注册和失败清理怎么处理

当清理动作有依赖时，可以按“谁依赖谁”的关系列一张小清单：

• 上层对象依赖连接、客户端或临时目录时，上层对象应先释放。
• 需要先执行的回调最后注册；不要只看代码离资源创建的位置近不近。
• 清理函数里遇到错误要记录上下文；不要悄悄覆盖测试主体已经报告的失败。
• 多个 goroutine 并发调用 Cleanup 时，注册先后可能是非确定的，不要用它编排业务顺序。

官方测试源码也覆盖了并发注册场景：回调本身会按某个顺序串行调用，但并发注册时的先后取决于调度，不能拿来当稳定契约。需要确定顺序，就把资源释放拆成一个明确的 Cleanup，或在单一回调中按依赖关系组织动作。

常见问题

Cleanup 和 defer 是同一个顺序吗？

都常见后进先出，但生命周期不同。defer 绑定当前函数返回；Cleanup 绑定测试对象，并会等待它的子测试完成。

子测试失败后 Cleanup 还会执行吗？

测试结束时仍会进入已注册的清理阶段，所以资源释放不应依赖测试主体是否成功返回。

能不能用多个 Cleanup 表达复杂事务回滚？

可以表达简单的分层释放，但跨资源的强顺序和错误传播更适合集中到一个回调中，或者由测试夹具显式管理，避免回调之间互相猜测状态。