Go 子测试 Parallel 怎样避免共享状态竞争

表格驱动测试加上 t.Parallel() 后，偶发失败通常不是断言本身不稳定，而是几个子测试仍在读写同一份状态。最常见的来源有三类：闭包引用了还会变化的用例变量、多个分支共用可变夹具，以及修改了整个测试进程的环境变量或工作目录。

解决思路是把“每个子测试自己的东西”和“整个进程只能有一份的东西”分开：用例数据在 t.Run 内固定，临时资源按子测试创建，进程级状态留在串行父测试；并行组结束后，再由父级继续清理。

官方文档：https://pkg.go.dev/testing

先确认竞争来自哪一种共享状态

t.Parallel() 表示当前测试要和其他并行测试一起运行，并会暂停到非并行测试结束。它不会自动复制闭包变量，也不会为你的全局变量、环境变量或工作目录创建副本。因此，看到“单独运行通过、整组运行偶发失败”时，先把共享对象列出来。

• 输入共享：循环变量、可变切片、指向同一结构体的指针。
• 资源共享：同一个临时文件、端口、数据库记录或内存缓存。
• 进程共享：os.Setenv、os.Chdir 和其他影响整个测试进程的状态。

这三类问题的修复位置不同。复制输入和隔离资源可以让子测试并行；进程级状态则应留在并行边界之外。

先把每个并发子测试的输入固定下来

表格驱动测试中，最稳妥的做法是让闭包捕获当前用例的副本，再调用 t.Parallel()。这样每个子测试读取的是自己的 name、input 和 want，而不是循环继续推进后的共享值。

func TestNormalize(t *testing.T) {
	cases := []struct {
		name  string
		input string
		want  string
	}{
		{name: "前后空格", input: "  go  ", want: "go"},
		{name: "空文本", input: "", want: ""},
	}

	for _, tc := range cases {
		tc := tc // 注释：复制当前用例，避免并发闭包读取变化中的循环值。
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel()
			got := strings.TrimSpace(tc.input)
			if got != tc.want {
				t.Errorf("结果=%q，期望=%q", got, tc.want) // 注释：只报告当前子测试的局部断言。
			}
		})
	}
}

这里的关键不是把所有测试都改成并行，而是明确输入的所有权。若用例里还包含切片或 map，浅复制结构体并不能复制底层数据；需要按测试需要复制切片，或在每个子测试中重新构造可变对象。

把资源隔离到子测试自己的边界

如果每个分支都要写文件，使用 t.TempDir() 取得独立目录；如果要注册释放动作，使用 t.Cleanup() 绑定到当前测试生命周期。资源创建和清理都放在子测试里，通常比让多个分支共享一个全局夹具更容易推理。

func TestEncodeFiles(t *testing.T) {
	cases := []string{"短文本", "多行文本"}
	for _, name := range cases {
		name := name // 注释：固定子测试名称，避免闭包依赖循环变量。
		t.Run(name, func(t *testing.T) {
			t.Parallel()
			dir := t.TempDir() // 注释：每个子测试拥有独立临时目录。
			path := filepath.Join(dir, "input.txt")
			if err := os.WriteFile(path, []byte(name), 0o600); err != nil {
				t.Fatal(err) // 注释：输入文件创建失败时停止当前子测试。
			}
			t.Cleanup(func() {
				// 注释：清理动作归属于当前子测试，避免误删其他分支资源。
				_ = os.Remove(path)
			})
		})
	}
}

TempDir 适合文件类夹具，但端口、数据库记录、缓存键仍需应用层提供唯一标识或独立实例。不要只因为测试函数调用了 t.Parallel()，就假设外部系统已经完成隔离。

把全局状态留在串行边界

testing.T.Setenv 和 testing.T.Chdir 会改变整个进程的环境或当前目录，官方文档明确指出它们不能在并行测试或有并行祖先的测试中使用。需要验证这类状态时，把设置动作放在串行父测试中；并行子测试只读取已经确定且不会被同时修改的配置，或者改为给被测函数显式传入配置。

func TestConfigVariants(t *testing.T) {
	// 注释：进程级环境设置放在串行父测试，不在并行子测试中修改。
	t.Setenv("APP_MODE", "test")

	t.Run("只读配置分支", func(t *testing.T) {
		t.Parallel()
		if got := os.Getenv("APP_MODE"); got != "test" {
			t.Fatalf("APP_MODE=%q，期望 test", got) // 注释：子测试只读取稳定配置。
		}
	})
}

更复杂的场景可以把配置封装为参数，而不是让业务代码在测试期间反复读取进程环境。这样既能降低竞争风险，也能让测试输入写在用例表里，失败时更容易定位。

让并行组有清晰的生命周期

父测试会等自己的子测试完成；把一组并行分支放进一个父级 Run，就能形成“组内并行、组外串行”的边界。父级 Run 返回之后，再执行共享夹具的清理动作，避免清理和并行分支同时发生。

func TestSharedFixture(t *testing.T) {
	fixture := newFixture()
	t.Run("parallel group", func(t *testing.T) {
		for _, name := range []string{"读路径", "读元数据"} {
			name := name // 注释：每个子测试只保存自己的只读场景名称。
			t.Run(name, func(t *testing.T) {
				t.Parallel()
				checkReadOnlyView(t, fixture, name)
			})
		}
	})
	// 注释：Run 返回后，组内并行子测试已经完成，再释放共享夹具。
	fixture.Close()
}

这个写法只适用于夹具确实支持并发只读访问的情况。如果子测试会修改 fixture，应改成每个分支创建自己的实例，或用明确的同步机制保护可变部分。不要用“偶发通过”代替资源所有权设计。

用命令把竞争范围缩小

先用 -run 只运行目标测试或子测试，再用 -parallel 调整并发上限，最后用竞态检测器检查真正的内存数据竞争。命令本身只负责缩小观察范围，不能替代输入和资源隔离。

# 注释：先只运行目标测试下名为“前后空格”的子测试。
go test -run 'TestNormalize/前后空格' ./...

# 注释：限制并行测试数量，观察共享资源是否仍会互相影响。
go test -run TestNormalize -parallel 2 ./...

# 注释：使用竞态检测器寻找并发读写同一内存位置的路径。
go test -race -run TestNormalize ./...

如果只降低 -parallel 就不再失败，说明问题可能被调度掩盖，并不代表代码已经安全。复查顺序建议固定为：输入是否逐用例绑定、可变资源是否独立、进程级状态是否移出并行边界、后台 goroutine 是否在测试返回前结束。

相关问题

为什么 t.Parallel 后还要复制循环变量？因为并发子测试的闭包可能在循环继续执行时才读取变量，复制当前用例才能固定输入。

所有测试都适合并行吗？不适合。依赖共享可变夹具、环境变量、工作目录或外部唯一资源的测试，应先完成隔离，或者保留串行边界。

父级 Run 为什么适合包住并行组？父级 Run 返回前会等待组内并行子测试结束，因此返回后的清理动作不会和这些分支重叠。

结语

避免 Go 子测试共享状态竞争，可以记住四个动作：复制每个用例的输入，为每个分支创建独立资源，把 Setenv/Chdir 这类进程级状态留在串行父测试，并用父级 Run 形成清理边界。这样 t.Parallel() 才是在可控边界内提升速度，而不是把隐藏共享状态交给调度器决定。