Go t.Parallel 放进循环后为什么测试数据互相覆盖

表驱动测试里给每个子测试加上 t.Parallel()，结果却发现多个用例像是在共享同一条测试数据，甚至所有断言都拿到了最后一轮的值。根因通常不是 t.Parallel 改写了切片，而是子测试闭包引用了循环变量，真正执行断言时循环已经继续向后走了。

修复重点是让每个子测试拥有自己的 tc。使用 Go 1.22 语言版本的模块已经采用每轮独立的循环变量；需要兼容更早模块时，在 t.Run 前显式写一份局部绑定最稳妥。之后再用 -race 排除测试数据或资源本身的并发写入。

先看一个会互相覆盖的表驱动测试

问题常见于下面这种结构：

func TestParse(t *testing.T) {
    cases := []struct {
        name string
        in   string
        want string
    }{
        {name: "empty", in: "", want: "0"},
        {name: "one", in: "1", want: "1"},
        {name: "two", in: "2", want: "2"},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 先登记并行资格，断言可能稍后才继续
            got := parse(tc.in)
            if got != tc.want {
                t.Fatalf("got %q, want %q", got, tc.want)
            }
        })
    }
}

看起来每次 t.Run 都传入了不同的名称，但名称求值和闭包里的 tc.in、tc.want 不是一回事。真正要检查的是闭包执行时读取的变量实例。

t.Parallel 为什么会放大循环变量问题

t.Parallel() 的含义不是“从这一行开始立刻开一个新 goroutine”。它会把当前子测试标记为可并行，并暂停该子测试；父测试可以继续调用后面的 t.Run。当父测试函数返回后，这些并行子测试才会在并行配额允许的范围内继续。

因此，旧循环变量语义下，所有闭包可能指向同一个 tc。循环结束时它已经是最后一项，多个子测试恢复后就会读取同一份数据。更危险的是：如果最后一项恰好通过，错误测试可能稳定地通过，却没有检查前面的用例。

按 Go 版本选择局部绑定写法

如果模块的 go.mod 使用 go 1.22 或更高语言版本，for 循环每轮会创建新的变量，闭包不会再因为旧的循环变量规则拿到同一个实例。不过团队仍可保留显式绑定，让代码意图对读者和旧模块都清楚：

for _, tc := range cases {
    tc := tc // 兼容旧语言版本，也明确表达“每个子测试独占一份输入”
    t.Run(tc.name, func(t *testing.T) {
        t.Parallel() // 子测试只读取自己的 tc
        got := parse(tc.in)
        if got != tc.want {
            t.Errorf("got %q, want %q", got, tc.want)
        }
    })
}

也可以把数据作为参数传给独立函数，减少闭包捕获：

for _, tc := range cases {
    tc := tc // 让传参和闭包都落在当前迭代
    t.Run(tc.name, func(t *testing.T) {
        t.Parallel()
        assertParse(t, tc.in, tc.want)
    })
}

这里不建议只改子测试名称或在断言前打印日志。名称可能已经在循环当轮求值，而闭包中的字段仍然是另一条读取路径。

怎么排除“真共享”而不是变量捕获

修复绑定后，如果数据仍互相覆盖，就检查测试本身是否共享了可变对象。重点看三类位置：

• 测试表里的切片、map、指针字段是否被被测函数原地修改。
• 多个子测试是否共用临时目录、环境变量、全局缓存或同一个 mock 实例。
• 父测试是否在子测试完成前清理了并行子测试仍要读取的资源。

先给输入做深拷贝或改成只读构造，再运行：

go test -race ./... # 检查共享内存读写是否存在真实数据竞争
go test -run '^TestParse$/two$' -count=20 # 重复一个子测试，观察问题是否可稳定复现

-race 能报告并发读写冲突，但不会告诉你循环变量绑定是否符合业务意图。两者要分开判断：前者是内存同步问题，后者是作用域和测试调度问题。

提交并行表驱动测试前的速查

每个循环子测试都可以快速过一遍这张清单：模块语言版本是否明确；旧版本是否在 t.Run 前写了 tc := tc；闭包是否只读当前用例；共享 map、切片、临时资源是否隔离；父测试的清理代码是否位于包住并行子测试的 t.Run 之后；最后是否用 go test -race 做过一次反向检查。

常见误区还有两个。第一，t.Parallel 只控制测试调度，不会自动复制输入。第二，升级到 Go 1.22 只能解决循环变量语义，不能替你修复共享缓存、全局状态或被测函数的原地修改。

相关问题

Go 1.22 以后还需要写 tc := tc 吗？

对于使用 Go 1.22 或更高语言版本的模块，循环变量已经按每轮创建，通常不再需要这行兼容写法；保留它也能把“每个子测试使用独立数据”的意图写得更明显。

为什么单独运行子测试时不复现？

单独运行可能绕开了多轮循环和父测试等待边界，也可能没有触发共享资源并发。应同时跑完整表驱动测试，并结合 -race 和明确的子测试名称定位。