Go t.Parallel 子测试为什么在父测试返回后才运行

在表驱动测试里，常见的现象是：子测试已经调用了 t.Parallel()，但真正的断言、日志或耗时操作却要等父测试函数返回后才出现。这不是调度失控，而是 Go testing 包刻意设置的同步边界。t.Parallel() 之前的代码仍在当前子测试中执行；调用它以后，子测试暂时挂起，父测试可以继续创建其他子测试，父测试函数返回后它们才进入并行运行阶段。

t.Parallel 把执行点停在哪里

Go 官方对 T.Parallel 的定义是：当前测试进入并行测试集合，并暂停到所有非并行测试完成之后。对嵌套子测试来说，还多了一层关键规则：并行子测试要等“调用它的父测试函数”返回。于是，下面的日志顺序并不表示子测试没有启动，而是 t.Parallel 把后半段暂时交还给了父测试。

func TestGroup(t *testing.T) {
    t.Run("case-a", func(t *testing.T) {
        // 这行发生在进入暂停点之前。
        t.Log("before parallel")
        t.Parallel()
        // 这行要等 TestGroup 的函数体返回后才继续。
        t.Log("after parallel")
    })
    // 父测试还能在这里创建其他子测试。
    t.Log("parent continues")
}

因此，看到 parent continues 先于 after parallel 是预期结果。t.Run 在子测试函数返回，或者子测试调用 t.Parallel 进入等待状态时就可以向父测试返回；测试框架仍会记录这个子测试，并在最终结束前等待它完成。

用 t.Run 组织一组并行子测试

并行表驱动测试的稳定写法，是让每个子测试先准备自己的输入，再在确认不再依赖父测试的共享状态后调用 t.Parallel()。并发数量由测试二进制的 -test.parallel 控制，不等于创建多少个子测试就一定同时运行多少个。

func TestPrices(t *testing.T) {
    cases := []struct {
        name string
        want int
    }{
        {name: "basic", want: 10},
        {name: "vip", want: 8},
    }

    for _, tc := range cases {
        tc := tc // 兼容旧 Go 版本，避免闭包复用循环变量。
        t.Run(tc.name, func(t *testing.T) {
            // 进入并行区前只读取本用例自己的值。
            t.Parallel()
            got := priceFor(tc.name)
            if got != tc.want {
                t.Fatalf("priceFor(%q) = %d, want %d", tc.name, got, tc.want)
            }
        })
    }
}

运行时可以用 go test -run TestPrices -test.parallel=2 限制同一测试二进制中的并行测试数。它只改变并行槽位，不会改变 t.Parallel 的父函数返回边界。若测试依赖数据库连接、临时文件或网络服务，还要把每个用例的资源隔离放在暂停点之前或放到用例内部，不能假设所有准备代码都在同一时刻执行。

父测试状态与循环变量的边界

最容易误判的是把父测试里的可变变量当成子测试的快照。例如父测试在创建完所有子测试前不断修改一个变量，子测试在 t.Parallel() 后读取它，就可能读到后来状态。循环变量问题在新旧 Go 语言版本之间也有差异，跨版本维护时显式写 tc := tc 仍然直观。

同样要小心 os.Setenv、os.Chdir、全局缓存和共享临时目录。它们影响进程或整个包，不能因为测试函数写在不同的 t.Run 里就认为已经隔离。需要独立资源时，优先在子测试中创建局部对象；必须修改全局状态时，避免与并行子测试混用，并为清理动作保留明确的生命周期。

一份可执行的排查清单

排查时先把 t.Parallel() 临时移到断言之后或暂时删除，确认问题是否来自暂停边界；再恢复并行，逐项隔离输入和资源。最后用不同的 -test.parallel 值重复运行，并配合 -count 观察是否出现数据竞争或顺序依赖。

常见问题

t.Parallel 会立刻启动一个新的 goroutine 吗？

不会。t.Run 本身在独立 goroutine 中运行子测试函数，但 t.Parallel 的职责是把当前测试登记为并行并暂停，后续代码要等父测试返回后才继续。

父测试返回后，测试函数会不会提前结束？

不会。父测试函数可以先返回，但 testing 框架会继续等待已登记的并行子测试完成，随后再确定父测试和整个测试二进制的结果。

为什么去掉 t.Parallel 后结果就稳定了？

这通常说明测试依赖共享状态、执行顺序或暂停点前后的生命周期。去掉它只是改变了调度，真正修复应放在输入快照、资源隔离和清理时机上。