Go go test T.Cleanup 注册在子测试中为什么执行顺序不同

在 go test 里，T.Cleanup 的顺序不是简单的“谁先注册谁先执行”。要先看回调属于哪个测试对象：同一个 *testing.T 内部按后进先出；父测试和子测试之间，则是子测试及其清理全部结束后，父测试才执行自己的清理。因此，父层资源不能因为子测试返回就立刻释放，注册位置也不能只凭代码缩进来猜。

同一个 T 内先看注册顺序，再看测试层级

官方文档把规则分成两个维度：清理函数要等当前测试和全部子测试完成后才调用，同一个测试对象上的回调采用后进先出。下面的代码用日志名表示清理动作，重点是顺序关系，不依赖某个具体业务资源。

func TestCleanupOrder(t *testing.T) {
    // 父层先登记，通常负责父层创建的共享资源。
    t.Cleanup(func() { t.Log("parent cleanup") })

    t.Run("child", func(t *testing.T) {
        // 子层回调只清理子测试自己持有的资源。
        t.Cleanup(func() { t.Log("child cleanup") })
        t.Cleanup(func() { t.Log("child assertion record") })
    })

    // 同一个父 T 的后注册回调会先于先注册回调执行。
    t.Cleanup(func() { t.Log("parent last cleanup") })
}

在 child 这一层，child assertion record 先于 child cleanup；子测试整体结束后，父层的 parent last cleanup 才先于 parent cleanup。不要把子层回调和父层回调放进一条全局栈里理解，它们属于不同的测试对象。

为什么 t.Run 返回后，父清理还没有马上发生

t.Run 会启动子测试并等待它返回；如果子测试调用了 t.Parallel，它会先暂停，等父测试函数返回后再进入并行阶段。父测试运行器会等待这些并行子测试完成，再运行当前层级的 cleanup。这个设计保证父测试仍能持有共享夹具，例如临时目录、测试数据库连接或一次性服务。

顺序可以压缩成一条判断链：

1. 先结束子测试主体。
2. 执行子测试自己的 cleanup，仍按该子测试内的后进先出。
3. 并行子测试全部越过等待屏障后，才进入父测试 cleanup。
4. 父测试 cleanup 执行完，父测试才向上层报告最终状态。

用资源所有权排查“顺序不对”

如果辅助函数内部也调用了 t.Cleanup，调用辅助函数的先后就是注册顺序的一部分。需要“先记录结果、后释放句柄”时，应先注册释放，再注册记录，利用后注册先执行的规则；更稳妥的做法是让每个回调只负责一个清晰的资源边界，避免在一个 cleanup 里隐式触发另一层测试动作。

常见问题

父测试的 Cleanup 会不会抢在子测试前执行？

正常的 t.Run 层级不会。父测试会等待子测试及其清理完成，再执行父层清理。

同一个子测试里注册两次，哪次先执行？

后注册的先执行。把它当作该测试对象自己的栈，不要和父测试的回调混排。

Cleanup 里能不能再调用 t.Run？

不应这样设计。清理阶段已经在收尾，测试层级应在主体执行期间建立；资源回收回调只做释放、记录和必要的失败标记。