Go testing.Parallel 与 Cleanup 的执行顺序如何理解

我第一次把 Go 子测试改成并行时，最容易混在一起的不是语法，而是三个“什么时候”：t.Parallel() 什么时候让出当前执行点，t.Run 什么时候返回，以及 t.Cleanup 什么时候真正释放资源。把这三个边界分开后，执行顺序就不再靠猜。

可以先记住一句话：Parallel 改变的是测试的调度资格；Run 负责等待子测试结束；Cleanup 绑定的是测试层级，并在该测试及其子测试完成后执行，多个清理函数按后注册先调用。

一、先把 Parallel、Run 和 Cleanup 的三个顺序拆开

testing.T.Parallel 的含义不是“从这一行启动一个 goroutine”。它表示当前测试愿意和其他并行测试一起运行，并在调用点暂停，直到同一父级下的非并行测试完成。真正的并行资格由测试框架管理。

t.Run 也有一个容易被忽略的边界：普通子测试会阻塞到函数返回；如果子测试调用了 t.Parallel()，Run 会先让它进入并行等待状态，但父测试仍会等待这个并行子测试完成后再返回。这样父测试后面的清理代码才不会抢跑。

二、用嵌套子测试理解 Parallel 的暂停点

下面这个例子把共享数据放在父测试中，再让两个子测试并行读取。关键不是输出顺序，而是 t.Parallel() 之后的代码不会立刻继续执行；父级先完成自己的非并行部分，子测试才会被放行。

func TestGrouped(t *testing.T) {
    // 父级夹具在创建并行子测试前准备好。
    fixture := "ready"

    t.Run("read-a", func(t *testing.T) {
        // 声明并行资格；调用点之后由测试框架安排恢复。
        t.Parallel()
        if fixture != "ready" {
            t.Fatalf("fixture = %q", fixture)
        }
    })

    t.Run("read-b", func(t *testing.T) {
        // 第二个子测试也只读取父级准备好的数据。
        t.Parallel()
        if fixture != "ready" {
            t.Fatalf("fixture = %q", fixture)
        }
    })

    // Run 返回前，两个并行子测试都必须完成。
    t.Log("parent body is complete")
}

因此不要把 t.Parallel() 当成无条件提速开关。若子测试会修改同一个可变对象、依赖进程级环境，或者使用非并发安全的共享夹具，调度资格本身并不能替你解决数据竞争。

三、Cleanup 到底绑定在哪个测试层级

t.Cleanup 注册的函数，会在“当前测试及其所有子测试完成”后调用。注册在子测试里的清理只负责那个子测试；注册在父测试里的清理，则要等父测试下面的子测试全部结束。多个 Cleanup 在同一层级注册时遵循后注册先调用，适合用来按相反顺序拆卸嵌套资源。

func TestResourceScope(t *testing.T) {
    // 父级资源覆盖所有子测试，因此在父级注册清理。
    shared := newSharedResource()
    t.Cleanup(func() {
        // 父级清理要等全部子测试结束后才释放共享资源。
        shared.Close()
    })

    t.Run("case", func(t *testing.T) {
        // 子级临时对象只属于当前子测试。
        temp := newTempResource()
        t.Cleanup(func() {
            // 子级清理先处理自己的对象，避免泄漏。
            temp.Close()
        })
        t.Parallel()
        use(shared, temp)
    })
}

这里的顺序重点是归属关系，而不是把所有清理函数简单理解成一条全局栈：子测试的生命周期先独立收束，父级 Cleanup 再等待整个子树完成；同一个测试对象上后注册的清理函数先调用。

四、写测试夹具时的取舍与常见误区

我现在会先问“资源服务于哪一层”，再决定在哪里注册 Cleanup。只服务一个子测试的临时目录、临时文件和客户端，放在子测试里；被多个并行子测试只读共享的资源，放在父测试里并在父级清理。这样比在每个子测试里重复创建一套资源更容易控制。

• 误区一：把 Cleanup 当成 defer 的全局替代品。它跟测试层级绑定，不会因为注册位置靠近某行代码就只覆盖那一行。
• 误区二：并行测试里调用进程级环境修改。Setenv 和 Chdir 会影响整个进程，官方文档明确不适用于并行测试或有并行祖先的测试。
• 误区三：用日志行顺序判断生命周期。并行测试的日志展示顺序不应当被当成资源安全边界，父级 Run 返回和 Cleanup 归属才是判断依据。

速记就是：先用 Run 划出测试树，再用 Parallel 标记可以并行的节点，最后把 Cleanup 放到拥有资源的那一层。需要复用的父级资源不要在父函数体结束处手动关闭，让测试框架在子树收束后执行父级清理。

相关问题

Q：调用 t.Parallel 后，当前函数会立刻继续执行吗？
不会。它会在调用点暂停，满足父级非并行测试完成等条件后才继续。

Q：父测试的 Cleanup 会不会先于并行子测试执行？
正常的测试层级语义下不会；父级 Cleanup 要等当前测试及其子测试完成。

Q：多个 Cleanup 的顺序怎么安排？
在同一个测试对象上按后注册先调用；如果资源分属不同子测试层级，还要先看各自的生命周期归属。