Go 1.22 之后循环变量捕获问题怎样判断

判断 Go 1.22 之后的循环变量捕获问题，第一眼不要只看本机的 go version，先看当前包所属模块的 go.mod。如果模块声明为 go 1.22 或更高版本，使用 := 引入的循环变量按每次迭代创建；如果模块仍声明旧版本，旧的循环变量语义仍然有效。

官方资料地址：https://go.dev/doc/go1.22

最实用的判断顺序是：先看模块的 go 行，再看循环变量是否被闭包带出当前迭代；不要把“安装了 Go 1.22”直接等同于“所有包都自动使用新语义”。

先看 go.mod 的 go 版本

Go 1.22 的变化按模块语义生效，而不是简单按编译器二进制的版本生效。打开产生问题的包所在模块，找到类似下面的声明：

module example.com/loopcheck

go 1.22 // 该模块启用每轮创建循环变量的新语义

可以先做一个快速判断：

因此，遇到“升级编译器后问题怎么还在”的反馈，先确认构建时加载的是哪个模块、哪个 go.mod，以及是否存在按文件生效的构建约束。模块版本是判断模块语义的入口，不能用机器上的默认工具链版本替代。

用最小闭包样例判断代码是否依赖旧语义

看见 for range 并不代表一定有 bug。需要继续问：循环变量是否被闭包保存，且闭包是否可能在当前迭代结束后才执行。下面的例子把闭包保存到切片中，正好能暴露这个判断点：

package main

import "fmt"

func main() {
	values := []string{"red", "green", "blue"}
	var prints []func()

	for _, value := range values {
		prints = append(prints, func() {
			fmt.Println(value) // 闭包捕获循环变量，执行时才读取 value
		})
	}

	for _, print := range prints {
		print() // 闭包在循环体外调用，属于跨迭代使用
	}
}

在 go 1.22 或更高版本的模块中，这个 for _, value := range values 使用每轮变量，闭包各自关联对应迭代的值。在旧模块中，循环变量可能被后续迭代覆盖，闭包看到的值就可能集中到最后一次迭代。这里的关键不是某个固定输出，而是变量的生命周期是否超出了当前迭代。

排查时可以把捕获点分成两类：

• 当前迭代内读取：闭包立即调用，或者变量只用于本轮同步计算，通常不属于经典的跨迭代捕获问题。
• 带出当前迭代：闭包放进切片、返回给调用方、交给 goroutine 或延后执行，需要结合 go.mod 判断语义。

旧模块怎样用 loopvar 做迁移检查

如果项目还使用 Go 1.21，可以用官方提供的预览方式观察新语义下的测试表现：

# 在 Go 1.21 中让测试预览每轮循环变量语义
GOEXPERIMENT=loopvar go test ./...

# 只检查一个受影响的包，先缩小迁移范围
GOEXPERIMENT=loopvar go test ./internal/worker

预览结果用于发现测试或业务代码对旧语义的依赖，不代表已经完成迁移。若测试依赖旧的“所有闭包读到同一个循环变量”行为，应先修正测试意图，再把模块的 go 行升级到目标版本。已经声明 go 1.22 的模块不需要再用这个实验变量模拟新语义。

显式给闭包传参仍然是清楚的兼容写法

即使项目已经使用 Go 1.22，显式传参仍能把“每个闭包拿到自己的值”写在代码表面，方便读者理解，也便于同一段代码被回移到旧模块时保持意图清晰：

for _, value := range values {
	go func(v string) {
		fmt.Println(v) // 参数副本属于本次闭包调用
	}(value)
}

不过不要机械地把所有 value := value 都保留下来。判断是否需要改动时，先看三件事：模块是否已经是 go 1.22、闭包是否跨迭代执行、代码是否还需要兼容旧模块。如果只是同步地在循环体内读取变量，额外复制通常不能解决一个实际问题。

还要注意声明方式。本文讨论的是循环中用短变量声明引入的 value；如果变量在循环外先声明，再用 = 反复赋值，就不能直接套用“Go 1.22 每轮变量”的结论，仍要按共享变量和闭包生命周期分析。

最后按这张清单完成判断

1. 打开产生问题的模块，确认 go.mod 的 go 行。
2. 确认循环变量是不是由 := 在 for 中引入。
3. 搜索闭包、goroutine、函数返回值和延迟调用，找出变量是否跨迭代存活。
4. 旧模块先用 GOEXPERIMENT=loopvar go test ./... 做预览，再决定升级模块或调整写法。
5. 需要兼容旧模块时，用显式闭包参数表达每次调用的数据边界。

归根结底，Go 1.22 之后循环变量捕获问题的判断依据是“模块语义 + 变量声明方式 + 闭包生命周期”三者的组合。只看编译器版本，或者看到闭包就统一加一行复制，都可能把真正的边界漏掉。

常见问题

安装 Go 1.22 后，旧模块会自动切换新语义吗？

不会只凭安装版本切换。先看模块的 go.mod；模块声明为 go 1.22 或更高版本时，才按新循环变量语义理解相关代码。

Go 1.22 之后还需要写 value := value 吗？

对使用新语义的短变量循环，经典的跨迭代闭包捕获问题通常不再需要靠这行复制修补。若代码还要兼容旧模块，或希望显式表达边界，可以改用闭包参数传值。

GOEXPERIMENT=loopvar 是生产运行参数吗？

它主要用于 Go 1.21 的迁移预览和测试检查。它不能替代模块升级，也不能代替对闭包生命周期的代码分析。

为什么 go 1.22 了仍然可能有并发问题？

Go 1.22 解决的是循环变量按迭代复用造成的捕获边界问题，并不会自动保护共享 map、slice、指针对象或其它可变状态。发现新语义后仍需单独分析这些共享数据。