Go t.Parallel 子测试为什么读到被修改的共享变量

我第一次遇到这个问题时，表驱动测试的每个 case 都没有报错，结果却像被“串台”了：子测试打印出的名称偶尔变成了后一个 case。排查后发现，问题通常不是 t.Parallel() 把值改坏了，而是它让子测试先暂停，外层循环随后继续修改了仍被闭包引用的变量。

最短的判断是：先看子测试在调用 t.Parallel() 后何时真正继续，再看循环变量是否受 Go 版本语义影响，最后检查变量里面是否还有指针、切片或其他可变共享对象。 Go 1.22 为满足条件的模块改变了循环变量的作用域，但它不会自动深拷贝结构体，也不会切断指针和切片的共享关系。

先看 t.Parallel 把执行点推迟到了哪里

t.Run 会启动一个子测试函数。子测试调用 t.Parallel() 后，不是立刻与外层循环并行跑完，而是把自己标记为并行测试并暂停；父测试函数返回后，它才会和其他并行测试继续执行。于是下面的闭包读取 tc 时，读取动作可能已经晚于外层循环对 tc 的下一次赋值。

func TestPrices(t *testing.T) {
    cases := []struct {
        name string
        want int
    }{
        {name: "small", want: 10},
        {name: "large", want: 100},
    }

    for _, tc := range cases {
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 先暂停，父测试返回后才继续执行本测试。
            t.Logf("case=%s want=%d", tc.name, tc.want) // 这里才读取闭包中的 tc。
        })
    }
}

这段代码的关键不在日志顺序，而在读取时机。按照 testing 包对 Parallel 的定义，调用点之后的代码可能要等父测试返回；因此外层 for 已经完成多轮推进并不奇怪。图 1 用时序关系把这个暂停点画了出来。

旧模块为什么容易读到最后一个 case

在 Go 1.22 以前，for 循环里声明的迭代变量通常是同一个变量，在每一轮被更新。闭包保存的是这个变量的引用，而不是当轮值的快照。表驱动测试又经常把 t.Parallel() 放在子测试开头，于是“先登记、后执行”的时序把这个问题放大了：多个子测试可能在恢复时看到同一个变量的最后状态。

在 Go 1.22 中，每次迭代会创建新的循环变量，目的是避免这类意外共享。不过这个规则受模块语言版本控制：模块的 go.mod 声明为 Go 1.22 或更高版本时，相关包使用新语义；旧模块不能仅因为本机安装了新工具链，就假定所有包都已经自动改成新语义。

兼容旧模块的写法：在闭包入口固定当前值

如果项目需要兼容旧版本，或者希望让读者一眼看到“每个子测试拥有自己的输入”，可以在 t.Run 前显式创建局部副本。这个副本不是为了修复 t.Parallel，而是把当轮值的所有权写清楚。

func TestPrices(t *testing.T) {
    cases := []struct {
        name string
        want int
    }{
        {name: "small", want: 10},
        {name: "large", want: 100},
    }

    for _, tc := range cases {
        tc := tc // 为旧模块保留当轮副本，闭包只捕获这一轮的值。
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 子测试的恢复时机不再改变 tc 这份局部副本。
            t.Logf("case=%s want=%d", tc.name, tc.want) // 读取固定后的输入。
        })
    }
}

在使用 Go 1.22 语义的模块里，这个写法通常是冗余的，但它仍然可以作为兼容性和可读性选择。不要把 “Go 1.22 修复循环变量问题”理解成“所有并行测试都安全了”；它只改变了循环变量的创建方式。

指针和切片仍然可能把共享状态带进子测试

真正容易被忽略的是：即使每轮的 tc 是一个新结构体，结构体字段里的指针、切片、map 或外部对象仍可能指向同一份可变数据。复制结构体只复制字段本身；复制切片只复制切片头，不会复制底层数组。

type testCase struct {
    name  string
    input []int
}

func TestInputs(t *testing.T) {
    shared := []int{1, 2}
    cases := []testCase{
        {name: "first", input: shared},
        {name: "second", input: shared},
    }

    for _, tc := range cases {
        tc := tc // 只复制结构体和切片头，仍共享 shared 的底层数组。
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel() // 并行读取前，必须确认没有其他测试修改 tc.input。
            got := append([]int(nil), tc.input...) // 需要独立数据时显式复制。
            t.Logf("input=%v", got) // 日志只展示本测试拿到的副本。
        })
    }
}

如果某个子测试会修改 tc.input，就不能只写 tc := tc；应在进入并行区域前复制切片，或让测试数据保持只读。若字段是指针，则要根据测试目标决定是共享同一个对象、为每个 case 构造对象，还是在访问处使用锁。图 2 将“循环变量隔离”和“对象内容隔离”分成了两层。

用最小复查清单定位到底是哪一层共享

我通常按下面的顺序排查，而不是先给所有测试加锁：

1. 确认暂停点：把 t.Parallel() 后的第一条读取语句标出来，判断它是否依赖父测试返回前会变化的变量。
2. 确认语言版本：查看目标包所属模块的 go.mod，不要只看本机 go version。
3. 确认闭包捕获：对旧模块或需要清晰表达的代码，在 t.Run 前绑定 tc := tc。
4. 确认深层字段：检查指针、切片、map、引用型接口和全局变量是否仍然共享；需要隔离时显式构造或复制。
5. 确认并发访问：如果测试确实同时读写同一对象，再用 go test -race 查数据竞争；不要用改变调度的手段掩盖共享状态。

# 在包级测试中打开竞态检测，优先确认是否存在真实并发读写。
go test -race ./...

# 只重复一个容易复现的测试，减少并行调度带来的偶然性。
go test -race -run '^TestInputs$' -count=20

竞态检测可以帮助发现并发读写，但它不能替你判断测试是否应该共享输入；一个只读共享对象可能完全没有 race，却仍然让测试意图不清。测试数据的所有权和修改权限，最好在代码结构里直接表达。

我会怎样选择修复方式

常见问题

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

如果目标包确实使用 Go 1.22 或更高的模块语义，单纯为修复循环变量捕获而写它通常不再必要。但项目需要兼容旧模块、团队更看重显式可读性时，保留这行也可以；它不能代替对指针和切片内容的隔离。

t.Parallel 会让所有子测试立刻同时开始吗？

不会。调用后子测试会暂停，等父测试返回后才参与并行执行；并行测试之间的具体调度顺序仍不应作为断言依据。

复制结构体后为什么输入还会被改？

结构体复制只复制字段值。切片、map、指针等字段仍可能指向同一对象或底层存储，需要按测试边界显式复制或构造。

只读共享变量需要加锁吗？

多个测试只读且对象没有其他写入时，通常不需要因为“共享”二字就加锁；但要确认初始化已完成、测试不会修改它，并避免把只读约定留在口头说明里。

官方资料可从以下地址继续核对：https://pkg.go.dev/testing#T.Parallel、https://go.dev/doc/go1.22、https://go.dev/blog/loopvar-preview。把问题拆成“暂停时序、循环变量语义、深层对象共享”三层后，t.Parallel 导致的错读通常就能定位到具体一层，而不是笼统归咎于并行测试。