Go testing.T.Parallel 子测试共享数据怎么隔离

表驱动测试加上 t.Parallel() 后，最容易踩的坑不是 goroutine 数量，而是多个子测试仍然指向同一份切片、map、请求对象或包级变量。处理这类问题的核心是：共享数据只能只读；凡是会被修改的输入、结果和临时资源，都在子测试边界内创建或复制。

为什么 t.Parallel 会让共享状态“晚一点”才被读到

t.Run 会启动子测试函数；当子测试调用 t.Parallel() 后，Go 测试框架会暂停它，父测试可以继续创建其他子测试。等同层的非并行测试完成后，这些子测试才恢复执行。也就是说，调用点之前的初始化和调用点之后的断言，可能处在两个完全不同的并发阶段。

如果父测试在 Run 返回后修改了共享 map，子测试恢复时看到的就可能不是创建它时的内容。父测试结束前框架仍会等待并行子测试，但“等待完成”不等于“自动复制数据”。

func TestUsers(t *testing.T) {
	// 这份 map 会被所有子测试捕获，不能在并行阶段继续修改。
	want := map[string]string{"alice": "admin", "bob": "viewer"}
	for _, name := range []string{"alice", "bob"} {
		name := name // 兼容旧 Go 版本时，显式固定本轮循环值。
		t.Run(name, func(t *testing.T) {
			// 调用后当前子测试暂停，恢复后可能与其他子测试同时运行。
			t.Parallel()
			if want[name] == "" {
				t.Fatalf("missing role for %s", name)
			}
		})
	}
}

把每个子测试的数据边界收紧

最稳妥的模式是把不可变模板放在外层，把可变对象在每次 t.Run 中创建。若模板包含 map、指针或嵌套切片，不能只做浅复制；要么写明确的深复制函数，要么在子测试中按字段重新构造。

func TestParseCases(t *testing.T) {
	tests := []struct {
		name  string
		input []byte
		want  map[string]string
	}{
		{name: "first", input: []byte("a=1"), want: map[string]string{"a": "1"}},
		{name: "second", input: []byte("b=2"), want: map[string]string{"b": "2"}},
	}

	for _, tc := range tests {
		tc := tc // 固定表项；下面的 map 和字节切片仍要各自复制。
		t.Run(tc.name, func(t *testing.T) {
			input := append([]byte(nil), tc.input...)
			want := make(map[string]string, len(tc.want))
			for key, value := range tc.want {
				want[key] = value // 创建子测试私有的 map。
			}
			t.Parallel()

			got := parse(input)
			if got[tc.name] != want[tc.name] {
				t.Errorf("got %#v, want %#v", got, want)
			}
		})
	}
}

这里的顺序有意把复制放在 t.Parallel() 之前：复制本身不与兄弟子测试竞争，恢复后的解析和断言才并行。若复制成本很高，也可以让所有子测试只读同一个不可变模板，但必须确认被调用的函数不会修改它。

用 t.Cleanup 管理资源，不要在并行测试里改进程状态

文件、临时目录、数据库记录这类资源应绑定到创建它的子测试。t.Cleanup 会在该测试及其子测试完成后执行，适合撤销本测试的写入。相反，环境变量、当前工作目录这类影响整个进程的状态不适合放进并行测试；官方文档明确限制了并行测试使用 t.Setenv 和 t.Chdir。

func TestConfig(t *testing.T) {
	t.Run("isolated", func(t *testing.T) {
		// 临时状态只归本子测试所有，清理动作也绑定在同一边界。
		path := makeTempConfig(t)
		t.Cleanup(func() {
			removeTempConfig(path) // 即使断言失败，也会执行清理。
		})
		t.Parallel()
		checkConfig(t, path)
	})
}

需要修改全局环境时，通常把这部分放在非并行的父测试中，或拆成单独的串行测试。不要用互斥锁掩盖所有问题：锁能保护一次写入，却不能保证不同子测试不会读到彼此留下的业务状态。

用 -race 和 -count 区分两种污染

先用 race detector 检查 map、切片或对象是否在没有同步的情况下被同时读写：

# -race 检查数据竞争，-count 增加调度变化带来的复现机会。
go test -race -count=20 ./...

一份可执行的隔离检查清单

提交前逐项问：子测试是否拥有自己的输入切片和 map？被测函数是否会修改传入对象？共享模板是否真正只读？资源清理是否使用 t.Cleanup？是否有包级缓存、随机数种子或环境变量残留？最后再运行 go test -race -count=20。如果业务本身依赖全局单例，宁可把这一组测试明确标成串行，也不要用偶然的执行顺序换取绿色结果。

常见问题

t.Parallel 一定会让测试更快吗？

不一定。复制大对象、争用锁或等待外部服务都可能抵消收益；先确认测试之间没有共享写入，再用测试耗时决定是否并行。

只写 tc := tc 就完成隔离了吗？

不一定。它只固定当前表项变量；如果表项里有 map、切片或指针字段，还需要复制这些底层可变数据。

加互斥锁后还需要复制吗？

如果共享对象就是被测的并发资源，锁可能是正确模型；如果共享只是测试夹具，复制通常更简单，也更能避免测试之间产生业务耦合。

父测试的 Cleanup 什么时候执行？

父测试及其子测试都完成后才执行。把并行子测试依赖的共享夹具清理写在父测试的 Cleanup 中，可以避免子测试尚未结束就释放资源。