Go 1.22 range 循环变量如何安全传入 goroutine：从旧写法到新语义

把切片元素交给 goroutine 处理时，Go 1.22 之前最容易踩到的坑是：闭包捕获了同一个 range 变量，几个并发任务最后可能读到同一个值。Go 1.22 为声明式 range 循环变量引入了“每轮一个变量”的语义，但它只对模块声明的 Go 版本生效，升级时仍要看清楚 go.mod 和测试边界。

新模块写 `go 1.22` 或更高版本后，`for _, v := range values` 的每次迭代都有独立的 `v`，闭包可以直接捕获；旧模块仍按旧语义编译，不能只凭本机安装的 Go 版本判断结果。

同一段 range 代码，为什么会打印出相同的值

先看一个最小实验。它没有业务噪音，唯一的并发动作就是把闭包放进 goroutine：

package main

import (
    "fmt"
    "sync"
)

func main() {
    values := []string{"a", "b", "c"}
    var wg sync.WaitGroup
    wg.Add(len(values))

    for _, v := range values {
        go func() {
            defer wg.Done()
            fmt.Println(v)
        }()
    }
    wg.Wait()
}

在旧语义下，range 循环声明的 v 属于整个循环，下一轮会更新它。goroutine 什么时候真正运行由调度器决定；如果它们在循环结束后才运行，看到的就可能都是 c。输出顺序本来就不保证，所以这里关注的是“值是否重复”，不是三行的排列顺序。

Go 1.22 把变量作用域改到了每次迭代

把模块的 go.mod 改成下面这样，声明式 range 的每次迭代会创建自己的循环变量：

module example.com/range-demo

go 1.22

此时上一段闭包可以直接保留，第一轮的 v、第二轮的 v 和第三轮的 v 彼此独立。Go 官方发布说明明确把这项变化放在 Go 1.22 的 for 循环语义中；规范也把“每次迭代有独立的声明变量”标记为 Go 1.22 行为。

旧模块为什么不能只看 Go 编译器版本

这项变化采用了按模块渐进切换的方式：模块的 go 行决定该包使用哪套语言语义。一个团队即使把开发机升级到了 Go 1.22，旧仓库的 go.mod 仍可能让代码继续使用旧行为。

这里别急着全仓库搜索替换。旧代码里常见的：

for _, v := range values {
    v := v
    go func() { fmt.Println(v) }()
}

在迁移到 Go 1.22 后可能变成多余声明，但也要先确认模块边界、构建约束和测试是否覆盖真实调用链。Go 1.22 的 vet 已经配合新语义调整了相关检查。

迁移时按什么顺序做验证

1. 先看模块边界。确认目标包实际归属哪个 go.mod，不要只看工作区根目录。
2. 再跑新语义测试。在升级提交前执行 GOEXPERIMENT=loopvar go test ./...，记录失败测试及其依赖包。
3. 检查并发输出。对捕获 range 变量的闭包运行 go test -race ./...；竞态检查不能证明业务值正确，但能帮助发现共享数据的另一层问题。
4. 最后清理兼容写法。只删除经过测试证明多余的 v := v，并把这类改动和版本升级放在容易回滚的提交中。

如果一个闭包还会访问外层的可变切片、计数器或复用对象，range 变量修复并不会自动解决那些共享状态问题。变量作用域变安全，不等于整个 goroutine 任务已经线程安全。

常见问题：range 闭包升级后怎么判断

只改成参数传递，是不是永远更稳

显式传参仍然是清楚且兼容旧模块的写法，例如 go func(item string) { ... }(v)。如果代码需要同时支持旧语言版本，或者读者一眼就要看到任务输入，保留参数传递没有问题；Go 1.22 的变化只是让直接捕获当前迭代变量不再有旧的循环复用陷阱。

为什么不能用输出顺序判断修复成功

goroutine 的调度顺序不稳定。验证时应断言收集到的值集合或排序后的结果包含 a、b、c，而不是写死打印顺序。

go.mod 写了 1.22，所有 for 循环都一样吗

本文说的是用声明语法创建迭代变量的 range 循环。普通三段式 for i := 0; i 的控制变量仍按自己的更新规则运行，不能把两种循环机械等同。

把版本切换和代码清理拆开

这次语义变化的价值不只在于少写一行 v := v，更在于把一个长期依赖经验的并发陷阱变成了语言规则。实际升级时，先用测试确认模块切换，再按调用点清理兼容代码；保留明确的提交边界，出现行为差异时才容易回退到旧版本逐项比较。