Go testing.T.Cleanup 如何控制执行顺序

我第一次把多个资源都交给 testing.T.Cleanup 时，最容易犯的错是按代码从上到下猜执行顺序。实际规则很明确：同一个测试作用域里，Cleanup 后登记的回调先执行；回调属于哪个 *testing.T，还决定了它要等哪个测试及其子测试结束。把这两层关系分开，清理顺序就不会再靠猜。

同一个 testing.T 上的 Cleanup 按“后登记、先执行”处理；有依赖的资源应先登记底层资源，再登记依赖它的上层资源。父子测试则按各自作用域管理，父测试的清理要等子测试全部完成。

先分清登记顺序和清理作用域

官方 testing 文档把 T.Cleanup 定义为：测试（或子测试）及其所有子测试完成后调用注册的函数，并且按照最后登记、最先调用的顺序执行。它和函数体里的 defer 都有逆序特征，但时间边界不同：defer 绑定当前函数返回，Cleanup 绑定测试作用域结束。

可以先用一个最小例子确认“同一个 T”的规则：

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

    // 先登记底层资源的释放回调。
    t.Cleanup(func() { got = append(got, "store") })
    // 后登记依赖 store 的上层资源。
    t.Cleanup(func() { got = append(got, "session") })

    // 这是示意输出：后登记的 session 会先进入 got。
    t.Logf("cleanup order is decided after the test returns")
}

示意结果是 session 再到 store。这里的关键不是变量名，而是两个回调都注册在同一个 t 上。若把其中一个改成子测试的 t.Run 参数，它就进入了另一个作用域，不能再用这段 LIFO 直觉直接推断。

用登记顺序表达资源依赖

设计清理时，我会先问一句“谁依赖谁”。例如事务依赖数据库连接，临时客户端依赖临时目录。正确做法通常是先创建并登记底层资源，再创建并登记上层资源。这样回调逆序执行时，上层对象先释放，底层对象最后关闭。

如果资源不是严格的栈关系，就不要为了“控制顺序”注册一串互相修改共享变量的回调。更稳妥的做法是把强依赖放进同一个 Cleanup，在其中显式完成一组动作，或者把资源拆到更合适的子测试作用域。Cleanup 适合做释放和复原，不适合隐藏业务断言。

父测试和子测试是两套清理边界

子测试的回调绑定在子测试自己的 t 上。父测试注册的回调，则要等父测试和它的全部子测试完成。这个区别很适合表达“每个用例一份资源”和“一组用例共享一份资源”：

func TestGroup(t *testing.T) {
    groupState := newGroupState()

    // 组级资源放在父测试，等待全部子测试结束后再释放。
    t.Cleanup(func() { groupState.Close() })

    t.Run("case-a", func(t *testing.T) {
        // 用例级资源只绑定当前子测试。
        item := newItem(groupState)
        t.Cleanup(func() { item.Close() })
        // 断言和操作写在这个子测试内部。
    })
}

结构上，item.Close 不应假设父级清理已经发生；而 groupState.Close 不应在某个子测试刚返回时就执行。并行子测试更要遵守这一点：t.Run 的父级不会在并行子测试真正完成前结束，所以组级 Cleanup 不能拿来抢先回收仍被子测试使用的共享对象。

并发注册和异常退出时的排查清单

文档保证的是注册到同一测试对象后的调用规则，不保证 goroutine 注册先后。若多个 goroutine 同时调用 t.Cleanup，回调本身会按顺序调用，但哪个回调属于“最后登记”可能受调度影响。因此不要把并发注册写成两个必须严格先后的释放协议；需要确定顺序时，先在主测试 goroutine 中完成登记，或让一个回调内部显式协调。

FailNow、SkipNow 这类结束当前测试 goroutine 的操作不会让已登记的 Cleanup 消失；但资源初始化失败时，仍应只登记已经成功创建的资源，并让关闭函数具备幂等性。遇到“清理顺序不对”，按下面顺序查：

1. 两个回调是否真的注册在同一个 *testing.T 上？
2. 是否把 defer 的函数返回边界误当成 Cleanup 的测试边界？
3. 资源依赖是否与登记顺序相反，或被分散到父子测试后仍共享同一状态？
4. 是否存在 goroutine 并发调用 Cleanup，导致登记时机不可预测？

实际项目里，我通常给清理函数保留一个简短的状态记录，在测试失败时只记录资源名和所属作用域，不依赖日志输出的排列来做断言。若顺序本身就是契约，则用一个专门的顺序切片或通道在测试中验证；普通业务测试则只验证“资源最终已关闭”，减少对实现细节的耦合。

常见问题

Cleanup 和 defer 可以互相替代吗？

不能完全替代。函数级临时变量适合用 defer，测试级资源尤其是要覆盖子测试的资源适合用 Cleanup。

Cleanup 一定按父级先、子级后执行吗？

不要把它简化成一条全局队列。先看回调属于哪个测试对象，再结合父测试要等待子测试完成的边界判断。

能否在 Cleanup 里继续注册 Cleanup？

不应把动态追加当成普通设计手段。需要复杂释放顺序时，集中到一个清理函数中表达依赖，通常更容易读和复查。

如何让 Cleanup 适配并行子测试？

共享资源放在父测试并等子测试全部结束，子测试自己的资源放在子测试回调里；不要在子测试仍可能访问时关闭父级共享对象。

把 Cleanup 看成“测试作用域结束时的逆序资源栈”，再把父子测试看成不同的归属边界，顺序设计就有了可复查的依据。真正需要固定的顺序，应由登记位置或回调内部逻辑明确表达，而不是依赖 goroutine 的偶然调度。