写 Go 这些年，几乎每个写过一段时间的人都在for range里吃过同一个亏——循环变量取地址、闭包捕获、协程 goroutine 里打日志，结果跑起来全是同一个值。这个坑我在各种技术群里几乎每周都能看到一次，有人换个写法就好了，有人折腾一晚上查不出原因，还有人把它当成了"Go 语言的 bug"到处吐槽。其实它背后有一套非常清晰的机制，搞懂了不但能把坑填平，顺带还能把 Go 的变量逃逸、闭包捕获、循环变量生命周期这几个概念一起理顺。

这篇文章就专门聊for range循环里的指针问题，会从最经典的翻车现场开始，一层层拆到根因，再给出一套可以直接抄的修复方案，最后附上我实际排查时用到的调试技巧和常见问题速查表。适合刚入门 Go 的读者，也适合写过不少业务但一直没深究过循环变量机制的朋友，面试前拿来突击也很有用。

1. 先把翻车现场摆出来

1.1 三个最常见的错误写法

第一种，也是流传最广的经典死法：在循环里取变量的地址，存进一个切片，循环结束之后发现切片里所有元素都指向同一个值。

func classicBug() { nums := []int{10, 20, 30, 40} var ptrs []*int for _, v := range nums { ptrs = append(ptrs, &v) } for _, p := range ptrs { fmt.Println(*p) } }

你预期输出10 20 30 40，实际输出大概率是40 40 40 40。我第一次跑出这个结果的时候整个人是懵的，反复确认了自己没取错变量名，然后又怀疑是不是fmt.Println有什么奇怪的行为，折腾半天才意识到问题出在v上。

第二种死法是闭包捕获，业务里出现频率极高，尤其是配合 goroutine 使用的时候。

func closureBug() { names := []string{"Alice", "Bob", "Carol"} for _, name := range names { go func() { fmt.Println(name) }() } time.Sleep(time.Second) }

这段代码在大多数版本上会打印三遍Carol，如果主函数提前退出，你甚至可能什么都没打印。换成 Python 或 JavaScript 里类似写法，闭包捕获的是各自迭代的变量，不会有这个问题，所以用惯了其他语言的开发者很容易在这里栽跟头。

第三种死法相对隐蔽一点：不直接取循环变量的地址，而是取结构体字段的地址。

type Item struct { ID int Name string } func structFieldBug() { items := []Item{ {ID: 1, Name: "one"}, {ID: 2, Name: "two"}, {ID: 3, Name: "three"}, } var result []*Item for _, item := range items { result = append(result, &item) } for _, r := range result { fmt.Printf("%d: %s\n", r.ID, r.Name) } }

这个问题的原理和第一种完全一样，但因为隔了一层结构体，很多人排查的时候第一反应是"我的数据源有问题"，而不是"循环变量有问题"。我见过有人因为这个 bug 把后端查数据的 SQL 改了三遍，最后才发现是取地址的位置错了。

1.2 这些 bug 的共同特征

把三个例子放在一起看，共同点非常明显：问题都出在对循环变量本身取地址或者把循环变量捕获进闭包。循环变量的值本身没有任何问题，fmt.Println(v)正常得很，但只要这个变量的"身份"被保留到迭代之后，就出事了。

这个特征给了我们一个非常重要的排查信号：如果你的代码涉及for range，并且循环体里出现了&取地址、闭包、goroutine、append到 slice、存进 map 这类操作，就要停下来想想循环变量的生命周期问题了。

另外，这类 bug 有一个特别讨厌的性质——它通常是间歇性的。如果是单线程同步打印，结果虽然错了但至少是"稳定的错"，好排查。一旦混入 goroutine，谁先执行、谁后执行完全看调度器心情，有时候打印三遍Carol，有时候打印Alice Bob Carol夹杂着Carol，这种玄学现象能把人逼疯。所以，如果你的代码里出现了"明明加了 goroutine 但结果时对时错"的情况，优先怀疑循环变量捕获。

1.3 为什么"值"看起来对，但"指针"不对

这是初学者最容易卡住的地方。我用一个生活化的类比来解释：循环变量v就像一辆循环使用的送货车，每次迭代range都会给这辆车装满当前这次的值，然后你把这辆车的车牌号&v记在单子上。等着几轮跑完，车停在最后一个货物旁边，你照着单子上的车牌号去找车，发现车里现在装的是最后一个值。

重点在于：货变了，车没换。v是同一个变量、同一个内存地址，只是这个地址上的内容在每次迭代中被重新覆盖。你存的&v从头到尾都是同一个地址，这个地址上的最终值是最后一次迭代写入的值，所以最后读出来全是最后一个。

这也是为什么代码里fmt.Println(v)在每个迭代时都正确——因为打印发生在"当次覆盖之后、下次覆盖之前"，你看到的永远是当前这趟车的货。但离开循环之后，车子最后一次停在哪、装了什么，就和你单子上记的场景完全脱节了。

2. 根因分析：Go 到底做了什么

2.1 循环变量复用机制

要真正理解这个坑，得看一下 Go 编译器在底层是怎么实现for range的。简单说，Go 1.22 之前，for range的循环变量是整个循环期间复用同一个变量的。

官方规范里有这么一句描述：每次迭代中，被 range 的表达式会重新求值一次，迭代变量会被赋值一次。但对for range的v来说，它在循环开始前只创建一次，之后每次迭代只是在同一个变量上做赋值。换句话说，传统for i := 0; i < n; i++里的i是什么生命周期，for range里的v就是什么生命周期，它们都不存在"每次迭代新建一个i"这种事。

这在绝大多数场景下是无害的，甚至是一种优化——少创建变量、少分配内存。但它有一个必然结果：&v永远指向同一个内存地址。

2.2 值拷贝与地址语义

第二个关键点是，for range对容器的遍历是值拷贝。不管你的切片里装的是int、string、struct，还是指针本身，v拿到的是当前位置元素的一次拷贝。

这引出一个很容易被误解的地方：如果容器里存的是指针，比如[]*Foo，那么v拷贝的是那个指针变量本身，*v指向的对象是不变的。这种情况直接存v或者&v都不对，正确做法是把指针本身拷出来用，或者通过索引取指针。

// 切片里存的是指针 foos := []*Foo{foo1, foo2, foo3} for _, f := range foos { // 错误：取循环变量的地址 result = append(result, &f) // 正确：直接把拷贝出来的指针 f 存进去 result2 = append(result2, f) }

这个细节看着不起眼，但非常重要。很多人以为"循环变量是拷贝，所以&v每次都是不同地址"，这是把两个概念搞混了。每次迭代确实发生了一次拷贝，但拷贝的目标是同一个变量，一个变量当然只有一个地址。

2.3 逃逸分析与"意外的 NEB"问题

Go 1.22 之前还有一个更隐蔽的问题，Go 官方曾经给过它一个专门的名字：loop variable is captured by func literal, but it escapes，常见简称是 "NEB bug"（No Escape Bug 的谐音梗）。

这个问题的背景是：当循环变量被闭包捕获时，编译器要做逃逸分析——闭包逃逸到堆上，捕获的变量也要跟着逃到堆上。在 Go 1.22 之前，编译器有个优化缺陷：它允许闭包直接复用循环变量的地址，不会为每次迭代创建新的堆变量。这导致不只是"所有迭代共享一个变量"，而更进一步变成"所有闭包共享同一个堆地址"。

这个 bug 最初是在github.com/golang/go/issues/16520被发现的，讨论了很多年，直到 Go 1.22 才以语言规范变更的方式彻底解决。如果你在用 Go 1.21 或更早版本，闭包捕获循环变量的坑是真实存在的，不是你的代码写得不对，而是语言实现确实有这个缺陷。

2.4 Go 1.22 带来的重要变化

在 Go 1.22 版本中，语言规范做了重大调整：每次迭代都会创建新的循环变量。也就是说，for range里的v不再是同一个变量，而是每次迭代都有自己独立的内存地址。

这意味着，如果你升级到了 Go 1.22 或更高版本，前面提到的三种经典写法在语义上都不会再共享地址了：

// Go 1.22+ 行为 for _, v := range nums { ptrs = append(ptrs, &v) // 每次 &v 都不同 }

这个变化是语言层面的，编译器和 runtime 都一起改了。但注意，它同时也是一个breaking change，个别在 1.21 时代依赖"循环变量复用"这个特性的代码可能会出问题，不过这种依赖方式本来就属于奇葩写法，现实中几乎没有。

这里给一个非常实际的建议：如果你的项目还在用 Go 1.20 或更早版本，尽快升级。不只是为了新语法，更是为了不要继续踩这个循环变量语义的坑。Go 1.22 的 release notes 里专门有一段讲这个变更，原话是 "In Go 1.22, each iteration of a loop creates new variables"，值得每个 Go 开发者读一遍。

3. 修复方案实操：从避坑到最优解

3.1 经典修复：循环体内创建局部变量

在 Go 1.22 之前，业界最通用、最朴素的修复方式就是在循环体内部创建一个局部变量，把循环变量的值拷贝一份，然后对这个局部变量取地址或捕获。这是官方在 FAQ 里推荐的写法，也是各种教程里最常见的方案。

// 修复取地址问题 for _, v := range nums { v := v // 局部变量 v 每次迭代都是新的 ptrs = append(ptrs, &v) } // 修复闭包问题 for _, name := range names { name := name go func() { fmt.Println(name) }() }

第一眼看到v := v这种写法的人通常都会愣一下，但它背后的逻辑非常清晰：外层是循环变量，内层用:=声明了一个同名新变量，这个新变量在每次迭代中都会被创建，因而不是复用的，取它的地址就不会有问题了。

这个写法的好处是兼容所有版本，Go 1.22 之前和之后都成立，而且代码改动量最小，不需要重写循环。缺点是v := v这行看起来有点反直觉，代码审查的时候经常有人问"这是干啥的"，需要有个注释说明。

3.2 索引访问：最直白的解决方式

如果你的容器支持索引访问，另一个很直观的修复方式就是不用range的 value，直接用索引。

for i := range nums { ptrs = append(ptrs, &nums[i]) } for i := range names { go func(idx int) { fmt.Println(names[idx]) }(i) }

这个方案的好处是语义极其清晰：nums[i]是切片中第几个位置的元素，取地址就是取那个位置元素的地址；i作为闭包参数传入，闭包捕获的是参数的副本，不是循环变量。几乎没有歧义，也不会被循环变量语义的变化影响。

但它也有自己的毛病。第一，不是所有容器都支持索引，map和channel就不行，你得换别的写法。第二，如果切片在循环过程中被并发修改，nums[i]可能和你预期的不一致，这在 Go 1.22 之前是隐患，在 Go 1.22 之后也依然是隐患。除此之外，频繁通过索引访问切片会有一次边界检查的开销，不过 Go 编译器对这种情况的边界检查消除做得已经不错，正常不用担心性能。

3.3 闭包传参：处理 goroutine 的首选

前面 3.1 里我已经展示了闭包传参的一种写法，更干净的做法是这样：

for _, name := range names { go func(n string) { fmt.Println(n) }(name) }

这个写法的核心思路是：闭包不捕获循环变量，而是在启动 goroutine 时把值作为参数传进去。Go 的函数参数是按值传递的，每次迭代调用go func(n string)都会把当前name的值拷贝一份传给参数n，闭包内部引用的是这个参数n，它和循环变量没有任何关系了。

这种写法有两个好处：一是完全不依赖 Go 1.22 的语义变更，前后兼容；二是参数名用n而非name，明确区分了"传进来的值"和"循环变量"，代码可读性更好。我在写并发代码时，遇到需要捕获循环变量的场景，几乎一律用这种写法，因为它是语义错误概率最低的方式。

3.4 不能取地址的场景：map 元素

到这里必须多提一嘴map，因为 map 的 value 取地址在 Go 里是根本不允许的。

m := map[string]int{"a": 1, "b": 2} for k, v := range m { // 编译错误：cannot take the address of m[k] // p := &m[k] _ = k _ = v }

原因在于 map 的底层是哈希表，元素在扩容、缩容、搬迁时会整体移动，地址不稳定，所以语言层面直接禁止了对 map 元素的取地址操作。如果你确实需要指向 map 中某个值的指针，正确做法是先用一个结构体中间层存储，或者直接改用别的数据结构，比如切片。类似的，string 的索引访问返回的是字节byte类型的临时值，取地址也没有意义，不要硬试。

3.5 公共函数库时的写法建议

如果你写的是基础库、中间件这类要被别人调用很多次的代码，我的建议是：不要依赖循环变量语义，也尽量不用裸&v，坚持用索引或者局部变量方案。因为你的调用方不一定了解这个坑，也没义务关心你用的是 Go 1.21 还是 1.22，公共库要保证的是最低版本下语义也正确。

我维护过一个小型工具库，之前图省事直接在for range里用了&v，配合 Go 1.20 跑得好好的，用户升级到 1.22 之后有"循环变量语义变更"的测试没过，反而给我报 bug。后来我把所有涉及地址捕获的地方全都改成了索引或局部变量方案，两边版本都兼容，再也没出过这档子事。公共库就是要这样，宁可代码笨一点，也要稳。

4. 常见问题排查与细节避坑

4.1 一段真实排查记录

有一次同事找我看一段代码，说"并发结果不稳定，有时对有时错"。那段代码结构大概是这样的：

func process(list []Task) { var wg sync.WaitGroup for _, t := range list { wg.Add(1) go func() { defer wg.Done() handle(t) // 闭包捕获循环变量 }() } wg.Wait() }

从表面看，这段代码结构和教科书里推荐的并发 worker 模式几乎一样，只是加了闭包捕获t。我第一反应就是"循环变量被共享了"，但同事不信，因为他觉得 Go 1.22 不是修了吗。

这里要澄清一个误区：Go 1.22 的修复是语言层面的循环变量语义变更，但如果你是在 Goroutine 里捕获循环变量，而 goroutine 的执行时机、调度顺序不确定，行为依然不稳定。严格说，Go 1.22 之后每次迭代都是新变量，闭包捕获的每个t确实独立了，但这只解决"变量共享"问题，解决不了"goroutine 打印顺序随机"这个天然属性。同事那个问题的真实原因其实是handle(t)里写了一部分日志、读了一部分状态，日志打印顺序和 goroutine 调度有关，看起来"时对时错"，但数据本身已经对了。

排查里我建议他做一个"同步版本复现"实验：把go func()改成直接调用，如果同步版本结果稳定，那就不是循环变量问题，而是 goroutine 调度顺序问题。这个实验只花了五分钟，立刻把问题定位了。

4.2 调试技巧：打印变量地址

遇到循环变量相关 bug 时，最高效的调试手段就是打印地址，而不是打印值。因为值在每次迭代里都是对的，只有地址暴露了"共享"这个事实。

for i, v := range nums { fmt.Printf("i=%d v=%v &v=%p\n", i, v, &v) }

如果在 Go 1.21 或更早版本，你会发现每次输出&v都是同一个地址；升级到 Go 1.22 之后，每次输出就各不相同了。有一次我在给一个初学者解释这个坑的时候，就是靠这张地址输出对比表让他恍然大悟的。类似的手段也适用于闭包：在闭包内部打印捕获变量的地址，能直接看出所有 goroutine 引用的是不是同一块内存。

另一个实用技巧是，如果你在调试一段并发代码，可以在 goroutine 里用go tool pprof抓 goroutine 栈，看闭包捕获的变量地址是否相同。不过这个方法对新手来说太重了，一般打印地址就够了。

4.3 其他语言同样有类似陷阱

这个坑虽然以 Go 最典型，但"循环变量被复用"的问题并不是 Go 独有。C/C++ 里，如果你在 for 循环里定义一个 lambda 并捕获引用，也会出一样的问题，尤其配合std::thread的时候：

std::vector<std::thread> threads; for (int i = 0; i < 10; ++i) { threads.emplace_back([&i]() { std::cout << i << std::endl; }); }

这里[&i]捕获i的引用，循环结束后i的最终值是 10，所有线程打印的几乎都是 10。正确的写法是用=i按值捕获或者传参数。JavaScript 里的var也有类似行为，不过用let就解决了，ES6 之后这个问题基本消失。

这些语言的共同点在于：闭包或匿名函数捕获的是一个"变量"还是"变量的拷贝"，以及这个变量在每次迭代里是不是新建的。理解了这一点，你在任何语言里遇到类似问题都能举一反三。

4.4 常见问题速查表

上面这个表基本覆盖了日常开发中所有 for range 指针相关的坑，建议收藏，写代码前扫一眼。

4.5 性能影响真的存在吗

聊完正确性，顺带说说性能。有些读者可能会担心：每次迭代都创建新变量，或者拷贝一份循环变量，会不会很慢？

实际上，这个担心在绝大多数场景下是多余的。局部变量的拷贝在寄存器或者栈上就能完成，开销是纳秒级别的，相对你的业务逻辑来说根本可以忽略不计。真正的性能风险在于逃逸：如果循环变量在某些写法下逃逸到了堆上，每次迭代都需要申请堆内存，那性能影响就大了。

有一个经典案例：在 Go 1.21 及之前版本，如果你在 for range 里写go func(){ use(v) }()，逃逸分析会认为捕获的变量逃逸到堆上，导致每次迭代创建一个堆对象；如果你改成传参的方式，编译器有时可以让参数在栈上传递，逃逸分析更友好。所以在高并发场景下，闭包传参方案不仅语义清晰，理论上性能也更好，这是一个双赢的优化。我在性能敏感的代码里从来不用捕获式闭包，不是矫枉过正，而是确实吃过去 GC 压力的亏。

5. 进一层：从 range 到语言设计思维方式

5.1 range 在不同容器上的行为差异

既然聊了slice的 range，顺带把map和channel的 range 也补齐。map的 range 顺序是随机的，而且每次迭代元素不一定连续；channel的 range 是不断接收直到关闭。这两类容器的 range 变量同样存在"复用"问题，但风险场景略有不同：

// map range 闭包捕获 for k, v := range m { go func() { fmt.Println(k, v) // Go 1.22 前 k/v 可能被复用 }() } // channel range 取地址 for v := range ch { ptrs = append(ptrs, &v) }

处理方式完全一样：要么用局部变量拷贝，要么用传参。我特别要提醒的一点是，map的 value 本身就不允许取地址，所以如果你在 map 的 range 里写&v，你得到的不是 map 里元素的实际地址，而是循环变量拷贝的地址，这个地址毫无意义，纯粹是让你误以为自己拿到了引用。这种"假引用"的写法是新手最容易产生理解偏差的地方。

5.2 这个坑为什么总被面试官拿出来问

如果你在准备 Go 相关岗位的面试，for range指针问题几乎是必考。面试官通常不会直接问"你知道这个 bug 吗"，而是让你现场写一段代码打印结果，或者让你修复一个有并发问题的代码片段。这个问题的考察点其实有好几层：

第一层，考察你知不知道循环变量复用的存在；第二层，考察你能不能解释根因，也就是v是同一个变量；第三层，考察你的修复方案是否多路——局部变量、索引、闭包传参，能说出几种；第四层，考察你对语言版本变更的了解，比如 Go 1.22 改了什么；第五层，考察你能不能把原理迁移到其他语言场景。

绝大多数候选人止步于第一层：知道有坑，见过别人踩，但自己写代码的时候照样踩。我的评价标准很简单，一个开发者如果能从"这个坑"深入讲到"闭包捕获、逃逸分析、值拷贝、版本兼容"这四个子话题，说明他碰到问题不止于"背答案"，而是真的消化了。面试前可以拿这个题目做一次自我检测，能连贯讲十分钟就说明基础扎实了。

5.3 我个人沉淀的 Go 循环写法习惯

踩过无数坑之后，我沉淀了一套自己的 for range 写法规则，在这里分享给大家：

规则一：在循环体内，永远不直接取循环变量的地址。不要因为 Go 1.22 改了语义就放松这条，因为你无法保证所有读到代码的人都知道这个安全边界。代码是写给人看的，不是写给版本号看的。

规则二：只要循环体内出现函数字面量（闭包），优先考虑把变量作为参数传入。除了避免指针陷阱，还能让闭包的行为更清晰，代码评审的人也更容易看出捕获关系。

规则三：如果需要收集切片中元素的指针，统一用索引方式。&s[i]的表达力比v := v; &v强很多，前者一看就知道取的是容器里真实元素的位置，后者需要多解释一句"这是为了规避旧版本 bug"。

规则四：升级到 Go 1.22 以上版本，并在 CI 里固定最低 Go 版本。语言语义变更对这种偶发性 bug 是最好的终结者。如果你的项目还在老版本，每看到一次循环变量相关的 bug 都要提醒一次：该升级了。

这些规则并不算复杂，但它们能帮我把"想起来容易踩坑"变成"压根不给自己踩坑的机会"。写代码的稳定性，很多时候就是从这种细小的习惯里堆出来的。

最后再分享一个我心里的小技巧：如果你被一个"时灵时不灵"的 Go 并发问题折磨，不要上来就怀疑 Go 运行时调度，先去检查所有闭包捕获了哪些变量，把它们全部换成参数传递。这一步能排除掉相当大一部分诡异 bug。我自己曾经在一个定时任务系统里查了两天问题，最后发现是循环变量捕获导致的“明明提交了 5 个任务，结果全在跑最后一个”，改完传参方式的当天，同事说“今天日志格外干净”。这类经验，踩过一次就不会忘。