Go testing.T.TempDir 在并行子测试中如何隔离目录

我在把一组文件处理用例改成并行子测试时，最先遇到的不是数据竞争，而是几个用例偶尔读到了彼此生成的文件。排查后发现，t.Parallel() 只改变调度方式，并不会自动把你手工创建的工作目录隔离开。要让并行子测试真正互不干扰，应当让每个子测试通过自己的 t.TempDir() 申请目录；如果在父测试里先申请一次再传下去，所有子测试仍会共享同一条路径。

t.TempDir() 的隔离单位是调用它的测试对象：每次调用都会得到独立目录，测试及其子测试结束后由 testing 自动清理。并行子测试应在各自的 t.Run 回调里申请目录，而不是复用父测试提前创建的可写目录。

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

让每个并行子测试在自己的回调里调用 t.TempDir

最小的安全写法是把目录申请放在 t.Run 的回调内。子测试调用 t.Parallel() 后会进入并行调度，但当前回调拿到的 *testing.T 仍然是它自己的测试对象。随后调用 TempDir，每个用例都会拿到唯一目录。

func TestRenderFiles(t *testing.T) {
	cases := []struct {
		name string
		data string
	}{
		{name: "invoice", data: "invoice-content"},
		{name: "report", data: "report-content"},
	}

	for _, tc := range cases {
		tc := tc // 固定当前用例，避免闭包读取变化中的循环变量
		t.Run(tc.name, func(t *testing.T) {
			t.Parallel() // 允许不同用例并行执行
			workDir := t.TempDir() // 当前子测试独占一个自动清理目录
			path := filepath.Join(workDir, "result.txt")
			if err := os.WriteFile(path, []byte(tc.data), 0o600); err != nil {
				t.Fatalf("写入测试文件失败: %v", err) // 写入失败立即结束当前子测试
			}
			got, err := os.ReadFile(path)
			if err != nil {
				t.Fatalf("读取测试文件失败: %v", err) // 读取失败不继续比较内容
			}
			if string(got) != tc.data {
				t.Fatalf("内容不匹配: got %q, want %q", got, tc.data) // 验证当前目录里的结果
			}
		})
	}
}

这里两个子测试都使用 result.txt，但路径形如不同的系统临时目录，因此不会因文件名相同而覆盖。需要注意循环变量捕获问题：如果代码运行在仍需手动固定循环变量的 Go 版本或团队兼容写法中，保留 tc := tc 更直观；它解决的是闭包取值，不是目录隔离。

不要把父测试申请的目录当作子测试隔离目录

下面这类写法看起来很省事，却把隔离边界提前抹掉了：

func TestSharedWorkDir(t *testing.T) {
	workDir := t.TempDir() // 父测试只申请了一份目录
	for _, name := range []string{"a", "b"} {
		name := name
		t.Run(name, func(t *testing.T) {
			t.Parallel() // 两个子测试会并行使用同一 workDir
			path := filepath.Join(workDir, "result.txt")
			if err := os.WriteFile(path, []byte(name), 0o600); err != nil {
				t.Fatal(err) // 这里的失败可能来自共享文件竞争
			}
		})
	}
}

问题不在 TempDir 失效，而在调用者把同一个返回值传给了两个子测试。只要它们会写文件、改配置或生成同名中间产物，就可能出现最后写入者覆盖前面结果、一个用例删除另一个用例文件等现象。若确实需要共享目录，应当把它明确定位为只读输入；可写工作区仍由每个子测试各自申请。

利用并行测试的等待边界理解自动清理

官方说明中，TempDir 创建的目录会在测试及其全部子测试完成后自动删除；而并行子测试在调用 t.Parallel() 后，会等待父测试中非并行部分结束，再与其他并行测试运行。实务上可以这样理解：父测试返回并不意味着仍在运行的并行子测试可以继续使用一个由父测试管理的可写目录；把目录申请和使用放在同一个子测试里，生命周期更容易对齐。

不要在 t.Run 返回后再检查子测试目录，也不要在另一个 goroutine 中把目录路径带出测试生命周期。测试完成后目录会被清理，路径即使还保存在字符串里，也不再是可靠资源。

用命名规则和清单排查临时目录误用

当并行测试偶发失败时，我会先做四项检查：第一，TempDir 是否出现在当前子测试回调内；第二，是否把父测试目录作为可写参数传给多个用例；第三，文件名是否固定但路径没有随测试变化；第四，是否有异步 goroutine 在测试返回后仍访问目录。只要其中一项成立，就先修复资源边界，再讨论提高并行度。

一个简单的取舍是：公共夹具可以在父测试中构造，但最好在构造后视为只读；每个子测试的输出、解压目录和临时配置，则统一放在自己的 t.TempDir() 中。这样既能共享昂贵的输入，又不会把可变状态带入并行执行。

常见问题

每个并行子测试都调用 t.TempDir，会不会生成目录太多？

目录数量与测试调用次数相对应，测试结束后会自动清理。相比多个用例争抢同一个目录，短生命周期的独立目录通常更容易排错；只有在测试确实需要共享大型只读数据时，才考虑父级准备输入。

父测试的 TempDir 能不能传给子测试读取？

可以，但应把它当作只读输入，并确保父测试不会在子测试运行期间修改或删除其中内容。只要子测试需要写入，就应改为在子测试内申请自己的目录。

t.TempDir 和 os.MkdirTemp 有什么区别？

os.MkdirTemp 只负责创建目录，清理责任需要调用方承担；t.TempDir 把目录绑定到测试生命周期，并由 testing 自动清理，更适合测试临时文件。