Go子测试t.Parallel设计共享夹具隔离的做法

Go 的 t.Parallel() 只负责声明调度关系，不会自动复制夹具，也不会给共享 map、slice 或数据库连接加锁。设计共享夹具时，最稳妥的分界是：只读数据可以共享，但任何会被子测试修改的状态都要在子测试内部创建、深拷贝或通过事务隔离。

先把 t.Parallel 的执行边界画清楚

t.Run 会建立层级化子测试。子测试调用 t.Parallel() 后会暂缓执行，直到父测试的非并行部分完成；随后它只和其他并行测试竞争并行额度。父测试不会因为调用了 Run 就提前结束，而是会等自己的并行子测试全部完成。

这意味着父测试适合准备只读基线，也适合在一个分组 Run 返回后做统一收尾，但不适合在子测试运行期间继续修改那份基线。下面的写法把每个 case 的输入绑定到局部变量，并明确把并行点放在子测试内部：

func TestNormalize(t *testing.T) {
	// 基线只在父测试中构造；并行子测试只读取它。
	base := newFixture()
	t.Cleanup(func() {
		// 所有子测试完成后再释放父级资源。
		base.Close()
	})

	cases := []struct {
		name  string
		input string
	}{
		{"trim", "  go  "},
		{"lower", "Go"},
	}
	for _, tc := range cases {
		tc := tc // 让每个子测试持有自己的 case 值。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			got := normalize(base, tc.input) // 只读访问共享快照。
			if got == "" {
				t.Fatalf("输入 %q 没有得到结果", tc.input)
			}
		})
	}
}

共享夹具要先区分只读和可变

“共享”本身不是问题，共享写入才是问题。字符串、数值、不可变配置快照通常可以直接复用；但包含 map、slice、指针或带内部缓存的结构体时，外层复制不等于深拷贝。一个常见误区是写出 local := base，却继续修改 local.Items，此时多个子测试仍可能指向同一张底层数据。

可变夹具放进子测试生命周期

当测试需要写入缓存、临时文件或数据库状态时，不要把“先共享、出问题再加锁”当作默认方案。更容易复查的做法是：子测试恢复运行后创建自己的夹具，注册对应的清理动作，测试函数只持有这份局部资源。

func TestSearch(t *testing.T) {
	cases := []string{"alice", "bob", "carol"}
	for _, name := range cases {
		name := name // 固定本轮子测试要使用的输入。
		t.Run(name, func(t *testing.T) {
			t.Parallel()

			fx := newFixture() // 每个并行子测试拥有独立的可变状态。
			t.Cleanup(func() {
				// 清理必须与本子测试的资源一一对应。
				fx.Close()
			})
			if err := fx.Seed(name); err != nil {
				t.Fatalf("写入测试数据失败: %v", err)
			}
			if got := fx.Search(name); got == "" {
				t.Errorf("没有找到 %q 的结果", name)
			}
		})
	}
}

Cleanup 会在测试及其子测试完成后执行，并且按后注册先执行的顺序调用。父级资源可以由父测试清理，子级资源由子测试清理，避免一个子测试替另一个子测试关闭对象。另一方面，t.Setenv 和 t.Chdir 会改变整个进程状态，不能放在并行测试或有并行祖先的测试里；需要这类操作时，应单独安排非并行测试组。

用 -race 和重复执行验证隔离

固定顺序通过，只能说明一次运行没有暴露问题。先按层级筛选目标子测试，再增加竞态检测和重复次数，能更快把共享写入、复用临时名称和遗漏清理暴露出来：

# 先只运行目标父测试，确认子测试命名和基本断言。
go test -run '^TestSearch/' -count=1 ./...

# 检查并行子测试是否存在未同步的共享读写。
go test -race -run '^TestSearch/' -count=1 ./...

# 放大调度次数，观察偶发的顺序依赖和资源残留。
go test -race -run '^TestSearch/' -count=50 ./...

如果只在高次数运行时失败，先看测试是否写了共享 map、复用了同一个临时目录或把 case 变量地址保存到了循环外。修复后再用 go test -race 复查；不要用增加 sleep 的方式掩盖竞态。

常见问题

t.Parallel 会自动复制父测试的变量吗？

不会。它只改变调度关系，变量、指针、map 和 slice 的引用关系仍由 Go 代码决定。

只读 map 能不能在并行子测试中共享？

可以，前提是初始化完成后绝不写入，也不调用会改变内部缓存的操作；任何写入都应改为深拷贝、加锁或每例创建。

为什么清理代码要用 t.Cleanup？

它绑定测试生命周期，能在子测试和其后代完成后执行，比散落的 defer 更容易覆盖提前失败和多层子测试。

实际设计时可以记住一句话：并行化的是测试任务，不是资源所有权。先把所有权划给父级只读快照或子级可变夹具，再开启 t.Parallel()，隔离边界才会稳定。