Go 旧版循环变量语义升级后测试为何变化

如果项目把 go.mod 从旧版本升级到 Go 1.22 语义，某些测试突然失败，并不一定是业务代码回归。最常见的原因是测试闭包捕获了 for 循环变量：旧语义下所有子测试可能在循环结束后读取同一个最终值，反而“误通过”；新语义会让每次迭代拥有自己的变量，于是隐藏的错误被暴露出来。

本文给出一套最小排查配方：先确认模块版本，再用 GOEXPERIMENT=loopvar 预览新规则，最后修正测试本身，而不是为了让旧结果继续通过而回退语义。

问题：为什么升级后 t.Parallel 测试变了

下面的测试表面上检查四个数字，实际却把循环变量 v 留给了延后执行的子测试：

func TestAllEven(t *testing.T) {
	// 1 不是偶数，测试应该明确失败，而不是被最后一次迭代掩盖。
	testCases := []int{1, 2, 4, 6}
	for _, v := range testCases {
		t.Run("value", func(t *testing.T) {
			// 并行子测试会等外层循环结束后再继续执行。
			t.Parallel()
			if v&1 != 0 {
				t.Fatalf("odd value: %d", v)
			}
		})
	}
}

旧循环变量语义下，所有子测试可能都读到最后的 6，因此测试错误地通过。启用每次迭代变量后，代表 1 的子测试会真实失败。这个失败通常是测试修复提示，而不是 Go 1.22 把断言改坏了。

最小配方：先用 loopvar 预览，不急着改模块

Go 1.21 提供了预览开关，可以在不立即修改 go.mod 的情况下，把当前模块及依赖按新循环变量语义编译测试：

# 在项目根目录执行，先观察受影响的测试。
GOEXPERIMENT=loopvar go test ./...

# 只缩小到一个包时，保留同样的语义开关。
GOEXPERIMENT=loopvar go test ./path/to/package

如果命令只在预览模式下失败，优先检查 t.Run、goroutine、回调和返回闭包是否引用了循环变量。修复测试后，再决定是否把模块声明升级到目标 Go 版本。

关键 CSS/JS：在 Go 项目里对应的是 go.mod 语义开关

这里的“配方开关”不是编译器全局版本，而是模块声明。Go 1.22 只对声明使用 go 1.22 或更高版本的模块采用每次迭代新变量；旧模块仍保留原来的循环变量含义，因此一个工作区内不同模块可能暂时表现不同。

module example.com/loopvar-demo

go 1.22

// 这里不需要手动写 v := v；每次迭代的 v 已经有独立作用域。
// 只有在兼容旧模块语义时，才需要显式复制并说明捕获意图。

可以用下面的对照表判断迁移范围：

变体与兼容坑：闭包复制不要机械保留

迁移前常见的保护写法是把循环变量复制一份：

for _, tc := range testCases {
	// 旧语义下显式复制，确保闭包捕获本轮用例。
	tc := tc
	t.Run(tc.name, func(t *testing.T) {
		// 子测试只使用本轮快照，避免延后执行时读到别的用例。
		t.Parallel()
		if got := normalize(tc.input); got != tc.want {
			t.Fatalf("got %q, want %q", got, tc.want)
		}
	})
}

在启用新语义的模块里，这个复制通常已经不再是必需的，但它仍可能表达“刻意保存快照”的意图。不要为了追求形式上的简洁一次性删除所有 x := x：先用 go vet 找出真实的逃逸引用，再结合闭包是否异步、变量是否被修改来决定。

还要注意兼容边界：声明 go 1.22 的模块不能由 Go 1.21 编译；升级工具链前应确认 CI、开发机和构建镜像的版本。若只想提前发现影响，可以先在旧模块上运行：

# 先检查循环变量闭包问题，再决定是否提升 go.mod。
go vet ./...
GOEXPERIMENT=loopvar go test ./...

完整片段：迁移时按这个顺序确认

1. 读取目标模块的 go.mod，确认 go 指令，而不是只看本机 go version。
2. 执行 GOEXPERIMENT=loopvar go test ./...，记录只在新语义下出现的失败。
3. 优先修正 t.Parallel、goroutine 和回调闭包中的测试数据捕获。
4. 重新运行 go vet ./...，删除或保留显式复制都要以捕获意图为依据。
5. 升级模块声明和 CI 工具链后，再跑一次完整测试矩阵。

一句话总结：Go 1.22 改变的是循环变量的作用域，不是断言的语义。旧测试升级后失败，往往说明它之前没有检查到每个用例；把失败定位到具体闭包和模块版本，迁移就会变成可控的测试修复。

常见问题

只升级本机 Go 版本，测试就会自动使用新语义吗？

不一定。模块的 go.mod 声明决定语义边界，本机版本只是工具链能力。旧模块可以用新工具链编译，但循环变量规则仍要按模块声明判断。

为什么普通顺序测试没暴露，t.Parallel 才暴露？

t.Parallel 会让子测试延后到外层循环结束后执行，旧语义下它们更容易共同读取最后一个循环值；顺序执行时闭包可能恰好在每次迭代内被调用。

官方资料：https://go.dev/blog/loopvar-preview、https://go.dev/doc/go1.22