Go t.Parallel 测试为什么共享临时状态会互相影响

Go 测试单独执行都通过，放进 table-driven test 后却偶发读到别的用例内容，最常见的原因不是断言写错，而是多个 t.Parallel() 子测试共享了同一份可变临时状态。父测试里创建的目录、固定文件名、可写 map 或指针，都会在并行子测试恢复后被同时读写。

解决思路是把“并行调度”和“测试夹具所有权”分开看：子测试可以并行，但目录、文件和可变对象必须按子测试独立创建；无法隔离的资源则不要强行并行。

t.Parallel 为什么让共享临时状态互相覆盖

t.Run 的回调一旦调用 t.Parallel()，当前子测试会先暂停，父测试可以继续创建其他子测试并最终返回。父测试返回后，这些子测试才会真正并行运行；同时运行数量还受 go test -parallel 限制。这个调度语义不会复制父测试里的目录、文件或对象。

下面的写法把所有用例指向同一个文件。每个子测试单独运行时看不出问题，批量并行时则可能在读取前被另一个用例覆盖：

func TestRender(t *testing.T) {
    // 父测试只创建了一份可变临时资源，所有子测试都会拿到它。
    sharedFile := filepath.Join(t.TempDir(), "result.txt")
    cases := []struct {
        name  string
        input string
    }{
        {name: "red", input: "red-result"},
        {name: "blue", input: "blue-result"},
    }

    for _, tc := range cases {
        tc := tc // 为每个回调固定本轮用例值。
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            // 这里的写入和读取会与兄弟子测试竞争同一个文件。
            if err := os.WriteFile(sharedFile, []byte(tc.input), 0o600); err != nil {
                t.Fatal(err)
            }
            got, err := os.ReadFile(sharedFile)
            if err != nil {
                t.Fatal(err)
            }
            if string(got) != tc.input {
                t.Fatalf("got %q, want %q", got, tc.input)
            }
        })
    }
}

这里的危险点是资源归属：sharedFile 属于父测试，却被多个并行子测试当成私有文件使用。固定文件名、包级缓存、复用的可写 map，以及父测试创建后传入的指针，都应按同样的方式排查。

用每个子测试自己的夹具隔离状态

最小修复是把临时目录的创建移进子测试，让 testing.T 为每个测试实例分配独立目录。目录路径不再由父测试共享，测试结束后也由测试框架负责清理：

func TestRenderIsolated(t *testing.T) {
    // 只保存不可变的输入表，资源在子测试内部创建。
    cases := []struct {
        name  string
        input string
    }{
        {name: "red", input: "red-result"},
        {name: "blue", input: "blue-result"},
    }

    for _, tc := range cases {
        tc := tc // 避免回调继续读取变化中的循环变量。
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            dir := t.TempDir() // 每个子测试拥有不同的临时目录。
            file := filepath.Join(dir, "result.txt")
            if err := os.WriteFile(file, []byte(tc.input), 0o600); err != nil {
                t.Fatal(err)
            }
            got, err := os.ReadFile(file)
            if err != nil {
                t.Fatal(err)
            }
            if string(got) != tc.input {
                t.Fatalf("got %q, want %q", got, tc.input)
            }
        })
    }
}

t.TempDir() 适合文件和目录型夹具，但不能自动解决所有共享状态。比如数据库仍然可能共用同一张表，环境变量会影响整个进程，单例对象也可能被多个测试修改。只读配置可以在父测试准备；可变数据要复制到子测试，或把这组用例改为串行。

怎么确认修复真的消除了共享状态冲突

先用 go test -run 'TestRender' -count=30 放大偶发问题，再用 go test -race 检查内存层面的数据竞争。-race 不能发现两个测试都合法写入同一个文件的逻辑冲突，所以还要在失败信息中打印 t.Name()、临时目录和资源键。若资源本身必须共享，设置更小的 -parallel 只能降低并发度，不能替代隔离设计。

常见问题

调用 t.Parallel 后，父测试里的清理会立刻执行吗？

父测试函数会继续向下执行并返回，之后并行子测试才获得运行机会；不要把“父函数继续执行”理解成“共享资源已经安全”。清理动作应绑定到正确的测试层级，并确保不会在子测试仍使用时删除资源。

把 -parallel 设为 1 能不能彻底解决问题？

它可以降低并发暴露概率，但不能修复错误的资源所有权，也不能替代独立夹具。后续提高并行度或改变测试顺序后，问题仍可能回来。

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

t.TempDir 直接和当前测试生命周期绑定，目录名也由框架管理；手写目录则需要自行处理清理、错误和测试层级。除非有特殊生命周期要求，优先使用 t.TempDir。

排查 t.Parallel 的核心不是先关掉并行，而是画出每个可变资源的所有权：谁创建、谁写入、谁清理。临时文件可按子测试拆分，不能拆分的资源就明确串行边界，这样速度和稳定性才不会互相牺牲。