Go 1.22 循环变量变化：for range 闭包坑为什么少了

搞Go的大伙肯定都踩过那个老生常谈的循环闭包坑：循环里起好几个goroutine，本来预期挨个打印1、2、3，结果跑出来日志全是同一个重复值，离谱得很。Go 1.22之后循环变量的语义终于贴合大部分人的直觉了，每一轮迭代都会单独生成自己的变量，这类闭包引用搞出来的怪事直接少一大截。不过项目迁移的时候还是得盯着go.mod里的版本配置、测试运行情况，还有那些早年故意靠旧语义写的边角逻辑，别掉坑。

为什么循环变量会成为老问题

这个坑从来不是语法多难搞，而是实际运行逻辑和正常人的第一反应完全对不上。很多开发者看到 for _, v := range values，下意识就觉得“每跑一轮都会新生成一个 v”。但老版本Go的语义里，这个变量其实就是循环外头提前开好的同一个内存位置，反复覆写值而已；要是闭包拖到后面延后执行，拿到的大概率是循环跑完最后覆写的那个值，根本不是你写代码时候预期的当轮值。

普通同步代码跑下来看不出任何毛病，一旦用到goroutine、回调函数、子测试、攒一堆后面才跑的延迟函数，这个坑立刻就炸出来了。线上出问题的时候往往不会直接抛错，就是日志不对、告警参数乱掉、传出去的请求值莫名其妙重复，排查起来特别磨人。

旧写法为什么容易踩坑

看个所有人都写过的最简复现代码，循环里挨个起goroutine，每个协程要打印当前轮的数值。老版本Go里，要是goroutine真正调度跑起来的时候循环已经走完了，它们全都会读到循环变量最后一次赋值出来的同一个结果。

package main

import (
    "fmt"
    "sync"
)

func main() {
    values := []int{1, 2, 3}
    var wg sync.WaitGroup

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

    wg.Wait()
}

为了躲这个坑，早年几乎所有Go项目都会在循环体开头补一行 v := v，手动造一个每轮单独的变量副本。这个写法谈不上优雅，但胜在稳，直接让闭包抓的就是当前轮的独立值，不会乱飘。

Go 1.22 的新规则改了什么

Go 1.22的改动说透了很简单：循环变量不会再像以前那样被多轮迭代共享，每跑一轮迭代就会新生成一个专属变量。这下闭包抓循环变量的时候，拿到的值就完全贴合你写代码时候的直觉了。

这个改动不光 range 循环受影响，普通 for 循环里的变量作用域也要结合实际写法判断。对大多数业务代码来说最直观的好处，就是goroutine、子测试里那些不得不写的循环变量拷贝样板代码能少一大半。

代码对比：哪些保护写法可以减少

早年几乎所有Go项目里的表格驱动测试都是这么写的：

func TestParse(t *testing.T) {
    cases := []struct {
        name string
        in   string
    }{
        {"empty", ""},
        {"number", "42"},
    }

    for _, tc := range cases {
        tc := tc
        t.Run(tc.name, func(t *testing.T) {
            t.Parallel()
            _ = parse(tc.in)
        })
    }
}

那行 tc := tc 存在的唯一目的，就是防止并行子测试拿到乱飘的循环变量值。新语义开了之后，这种纯用来兜底的写法大部分都没必要留了。但迁移的时候别上来就全局搜索批量删掉，有些变量拷贝可能本来就带别的作用，比如手动缩短变量生命周期、避免指针别名、特意给后续看代码的人标清楚这是独立副本。

兼容旧项目时要看哪些地方

Go 1.22的循环变量改动是跟着模块声明的版本走的。也就是说同一段代码，放在不同go版本声明的模块里，跑出来的语义完全不一样。迁移的时候先看 go.mod，再决定要不要调整对应的测试和业务逻辑。

module example.com/shop

go 1.22

最容易被忽略的坑是那些“跑了好几年都没出过错”的老测试。老版本语义下，错误的闭包写法反而可能让所有子测试都读到同一个值，歪打正着测试没报错过；新语义把每轮变量拆独立之后，测试才开始真实跑不同的用例，藏了好几年的逻辑bug直接就冒出来了。

项目里要是有下面这些写法，升级的时候建议单独拉出来走一遍review：

• 循环里起goroutine，闭包里直接用了循环变量。
• 循环里调用 t.Run，子测试逻辑里又用到了 t.Parallel。
• 循环里把闭包追加到函数切片里，攒到后面统一挨个调用。
• 循环里直接取循环变量的地址，或者把指针塞到外面的结构体里存着。
• 老代码里到处都是 x := x 这类专门防坑的兜底写法。

采用建议：先让测试说话

这种语言级别的语义改动，别拍胸脯说自己凭经验一眼扫过去就没问题。稳当点的做法是先拉个分支把go.mod里的版本切到支持新语义的版本，全量跑一遍单元测试和核心链路的集成测试，看失败用例集中在哪些包就行。测试跑挂不是坏事，很多时候反而帮你揪出了之前好几年都没测准的闭包隐藏bug。

按照这个节奏处理基本不会踩大雷：

1. 先把本地和CI流水线的工具链升级到位，全量跑一遍所有测试用例。
2. 挨个排查失败的用例，重点盯表格驱动测试和带并发逻辑的测试。
3. 把那些纯用来防闭包坑、本身没别的语义作用的拷贝删掉，留着那些特意给读代码的人标独立副本的 v := v。
4. 给取循环变量地址、攒闭包队列、批量起goroutine这几类代码加个专门的review备注。
5. 灰度放量之后盯紧错误日志和核心任务的运行结果，别光看编译过了就直接发全量。

常见问题

Go 1.22 后还需要写 v := v 吗？

大部分专门用来躲循环闭包坑的 v := v 都没必要写了，但别上来就全量批量删掉。有些留着它本来是为了给读代码的人明确标出来这是当前轮的独立副本，这种可以留着不用动。

旧项目升级后会不会直接编译失败？

几乎不会因为这个语义改动直接报编译错。更常见的情况是测试结果突然变了，或者之前藏了好几年没暴露的逻辑bug直接跑出来了。

只影响 range 循环吗？

大伙讨论最多的是 range，但普通 for 循环里的变量语义也要跟着Go 1.22的规则走，迁移的时候别只搜 range 就完事。

为什么这个变化要和 go.mod 里声明的版本绑定？

这样给老项目留足了兼容的缓冲空间。项目不用刚换完工具链就被迫适配所有新语义，完全可以通过go.mod的版本声明自己控制迁移节奏，想什么时候切新语义就什么时候切。

小结

Go 1.22这次对循环变量的调整，直接解决了存了好多年、一不留神就踩的闭包陷阱。新写的代码顺着直觉写就能跑对，体验爽很多；老项目借着这个机会把所有带循环闭包的逻辑全查一遍，顺带还能挖出之前藏着没发现的问题。别光盯着代码能不能过编译，多跑两遍测试比啥都稳。