Go testing.T.Parallel 调用后为什么要等待父测试返回

在表驱动测试里给子测试加上 t.Parallel() 后，常见现象是：循环很快结束，子测试却要等父测试函数返回才继续。这个等待是设计好的同步边界，不是 goroutine 卡死。t.Parallel() 会把当前测试标记为可并行测试并暂停它；父测试函数返回后，测试框架才会释放这一组并行子测试。

t.Parallel 为什么不会立刻执行后半段

testing.T.Parallel 的含义不是“新开一个 goroutine 后继续向下跑”，而是“把当前测试加入并行组，并在这里暂停”。t.Run 本身会启动子测试函数，并等待它返回；如果子测试调用了 t.Parallel，它会先向父测试报告“我已到达并行点”，随后挂起，t.Run 才能返回。

父测试继续执行后，可能创建更多子测试，也可能执行收尾代码。只有父测试函数真正返回，框架才释放这组已经登记的并行测试。此时它们最多按照 -parallel 指定的并发数运行。换句话说，等待的是父函数的生命周期边界，而不是某个网络请求或锁。

调用`t.Parallel()`之后子测试要等父测试返回才真正执行，本质是Go原生测试框架的同步机制设计，用来控制并行测试的执行时序，避免不同测试阶段的用例互相干扰，同时保障测试输出的可读性和资源隔离性。

表驱动测试中的正确生命周期

下面的写法把每条用例放进并行组。tc := tc 让闭包持有当前迭代的副本；它对需要兼容旧版 Go 的代码尤其稳妥。父测试先完成所有 Run 调用，离开函数后，子测试才开始真正并发执行。

func TestParseUser(t *testing.T) {
	// 父测试内准备的资源要覆盖所有子测试的生命周期。
	cases := []struct {
		name string
		input string
		want string
	}{
		{"empty", "", "unknown"},
		{"admin", "admin", "admin"},
	}

	for _, tc := range cases {
		tc := tc // 绑定当前循环变量，避免闭包读到别的用例。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel() // 到达并行点后暂停，等待父测试函数返回。
			got := parseUser(tc.input)
			if got != tc.want {
				t.Fatalf("parseUser(%q) = %q; want %q", tc.input, got, tc.want)
			}
		})
	}
	// 这里的代码仍在并行子测试释放前执行，不能提前销毁共享资源。
}

这个结构有两个容易混淆的结果：第一，父函数里的循环不会被每个子测试拖住；第二，父测试对应的 t.Run 组最终仍会等待所有并行子测试结束，所以父测试结束后再进入的顶层测试不会与它们无序交错。

哪些代码不能放在并行子测试里

并行测试适合读取独立输入、访问隔离的临时目录或使用只读共享配置。不适合随意修改整个进程的环境。比如 t.Setenv 和 t.Chdir 会影响进程级状态，当前测试或祖先测试已经并行时，testing 包会拒绝这种组合。数据库表、全局变量和固定端口也要明确隔离，否则并行只会把竞态放大。

共享夹具可以由父测试创建，并用 t.Cleanup 注册清理；不要在父函数刚提交完 Run 就手动关闭连接。子测试若需要独占状态，优先在子测试内部创建资源，或把用例数据复制一份。判断标准很简单：父测试返回前，资源必须仍然有效。

用最小实验确认调度，而不是猜输出顺序

排查“为什么还没执行”时，先给父测试、t.Run 前后和子测试并行点打印带名称的日志，再用 go test -run TestParseUser -v -parallel=1 缩小变量。-parallel=1 只限制并行测试的同时运行数量，不会取消“等待父测试函数返回”的规则。恢复默认并发后，再确认用例是否共享文件、环境变量、端口或可变全局状态。

相关问题

t.Parallel 会让父测试也并行吗？

不会。它标记调用它的测试；父测试函数仍按自己的顺序运行。父测试返回后，子测试才和同组其他并行测试竞争并发槽位。

为什么 t.Run 返回了，子测试还没完成？

子测试在调用 t.Parallel 时已把执行权交回框架，因此 t.Run 可以先返回；但外层父测试整体完成时，框架仍会等待这些子测试。

怎么控制并行子测试的数量？

用 go test -parallel=N 设置同时运行的并行测试上限，同时保证每个用例的资源和输入互不污染。