获课：xingkeit.top/10181/

for 循环闭包陷阱：彻底搞懂 Go 循环变量捕获问题

每一个Go初学者几乎都会踩进同一个坑：在循环里启动goroutine，或者用defer注册回调函数，结果运行时发现所有的操作都使用了循环的最后一个值。这个令人困惑的问题在Go社区里有一个专门的名字——循环变量捕获陷阱。它不是Go语言的Bug，而是变量作用域和闭包机制共同作用下的必然结果。

现象：同一个变量被反复捕获

先描述一下这个经典场景。你在一个for循环里遍历一个切片，每个元素启动一个goroutine去做异步处理，你预期每个goroutine拿到的是对应位置的元素。但实际运行时，所有goroutine输出的都是最后一个元素的值，或者更准确地说，是循环结束后的最终值。

这个现象让很多从其他语言转过来的开发者感到费解。在JavaScript或者Python里，类似的代码虽然有异步问题，但至少每次迭代的变量值是独立传入的。Go的情况更微妙，因为它涉及到循环变量的内存地址是否变化这个关键问题。

根源：循环变量在Go中只有一个

要理解这个问题，需要先弄清楚Go中for循环的变量生命周期。在Go的早期版本到1.21之前，for循环里的迭代变量在整个循环过程中只有一个实例。每次迭代结束时，这个变量的值被更新为当前元素，但它的内存地址始终不变。

这就意味着，如果你在循环内部创建了一个闭包——无论是通过go关键字启动的goroutine还是用defer延迟执行的函数——这个闭包捕获的不是“当前迭代的值”，而是“这个变量本身”。当闭包最终被执行时，循环早已结束，变量的值是最后一次迭代赋予的值。所有闭包共享同一个变量，自然输出同一个结果。

这个过程如果用一句话概括就是：闭包捕获的是引用，不是值。它们在等待执行的这段时间里，引用的变量一直在被循环修改。

修复思路：让每个迭代有独立的变量

明白了根源之后，解决方案就变得清晰了——让每次迭代都产生一个独立的变量副本，让闭包捕获这个副本而不是共享的循环变量。

最常见的做法是在循环体内部声明一个局部变量，把当前迭代的值复制进来。这样每个迭代都有一个独立的内存地址，闭包捕获的是这个局部变量，彼此互不干扰。另一种更简洁的方式是利用函数参数传递——在启动goroutine或defer时，将当前值作为参数传入匿名函数，参数在函数调用时被求值，自然就固定住了当前的值。

两种方式本质上都是在打破“共享同一个变量”的局面，让每个闭包拥有属于自己的数据副本。从Go 1.22开始，语言层面直接修复了这个陷阱，for循环的迭代变量在每次迭代时都会被重新声明，闭包捕获的行为从此符合绝大多数人的直觉预期。

不止goroutine，defer同样受困

同样的陷阱不止出现在goroutine里，defer语句也有完全一样的问题。在循环中使用defer注册清理函数时，如果闭包里引用了循环变量，最后执行时也会发现所有延迟函数都使用了最后一个值。

区别在于，defer的执行时机是函数返回前，此时循环早已结束，变量的终值已经确定。这个问题在文件操作等场景中尤其危险——你可能本意是在循环中逐次打开文件并延迟关闭，结果所有的延迟关闭操作都指向了最后一个文件句柄，前面的句柄永远不会被关闭，资源泄漏就这样悄无声息地发生了。

更隐蔽的场景：取地址和切片引用

除了闭包，循环变量陷阱还以另一种形式出现——取地址操作。如果你在循环里把变量的地址存入一个切片，循环结束后遍历这个地址切片并解引用，你会发现所有的值都一样。原因和闭包完全一致：地址是同一个，指向的内存位置从未改变。

这种模式在构造数据结构时偶尔会出现，比如你需要把多个对象的指针组织成一个列表。如果不小心把循环变量的地址存了进去，构造出来的列表就是一堆指向同一个内存位置的指针，数据全部错乱。排查时往往要追溯到很远的地方才能发现问题根源。

语言演进与最佳实践

Go 1.22对循环变量语义的修改，可以说是对开发者反馈的积极回应。但即便语言层面已经修复了这个陷阱，理解背后的原理依然有价值。原因有两个：一是大量存量代码仍然运行在旧版本Go上，维护这些代码需要理解旧语义；二是即使在新版本中，过度依赖语言特性而不理解变量捕获的底层机制，迟早会在其他类似问题上吃亏。

更重要的是，这个陷阱暴露了一个更深层的编程原则：并发环境下的变量共享需要格外谨慎。无论是闭包、goroutine还是channel，在传递数据时都要明确问自己——我是传值还是传引用？被共享的变量会不会在被使用前被修改？养成这种思维习惯，远比记住一个语法糖更有意义。

for循环闭包陷阱看似是一个小问题，但它背后涉及变量作用域、闭包捕获机制、并发执行时序三个核心概念的交叉。一次性吃透它，你对Go语言这些底层机制的理解会上一个大台阶。别嫌它基础，真正的高手恰恰是对这些基础细节有绝对掌控力的人。