Go 1.22起for range循环变量每次迭代创建新变量，不再复用同一地址，影响闭包捕获、goroutine行为及指针取址；旧版依赖地址稳定的代码需重构以兼容。
Go 1.22 的 for range 循环变量不再复用意味着什么
Go 1.22 起，for range 中的循环变量（如 v）在每次迭代中都会创建**新变量**，而不是复用同一内存地址。这不是语法糖变化，而是语义级变更——直接影响闭包捕获、goroutine 启动、指针取址等行为。
典型错误现象：for _, v := range items { go func() { fmt.Println(v) }() } 在 Go 1.21 及之前会打印多个相同的末尾值；Go 1.22 起默认打印正确值（但别依赖它“修好了”，得理解为什么）。
- 本质是编译器为每次迭代生成独立的变量绑定，而非在循环外声明一个变量再反复赋值
- 不改变
range对切片/映射/通道本身的遍历逻辑，只影响循环体内的变量生命周期 - 对性能无显著影响：现代编译器本就会做逃逸分析优化，新增变量不等于新增堆分配
哪些代码会因 Go 1.22 的 for range 变更出问题
不是所有旧代码都崩，但以下模式必须检查：
- 显式取循环变量地址：
&v，尤其用于传入函数或存入切片时——Go 1.22 下每次&v指向不同地址，而旧版指向同一地址 - 在 goroutine 或闭包中直接引用
v，且期望它“冻结”住当前迭代值（旧版靠 bug “凑合用”，新版行为变正交，但逻辑可能仍错） - 用
v做 map key 或 struct field 初始化，且假设其地址稳定（比如做对象池索引）
示例：m := make(map[*int]string); for _, v := range []int{1,2} { m[&v] = "x" } —— Go 1.21 中 m 最终只有 1 个 key；Go 1.22 中有 2 个 key，但值都指向最后迭代的 v 内存（因为 v 是每次新建，但生命周期到循环结束）。
立即学习“go语言免费学习笔记（深入）”；
如何安全地兼容旧逻辑（比如要复用变量地址）
如果真需要旧版“变量复用”效果（极少数场景，如某些底层缓存或调试工具），不能靠降级 Go 版本，而应显式控制变量作用域：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 用传统
for i := range items+ 索引访问，避免引入v变量 - 在循环体内手动声明一个外部变量并复用：
var v T; for _, item := range items { v = item; ... } - 若需地址稳定，就提前分配好空间：
vs := make([]T, len(items)); for i, item := range items { vs[i] = item; ptr := &vs[i]; ... }
注意：for i := range items { v := items[i] } 这种写法在 Go 1.22 下 v 仍是每次新建，和 for _, v := range items 行为一致——别误以为换写法就绕过变更。
升级 Go 1.22 后最该 grep 的代码模式
用以下命令快速定位高风险点：
grep -r 'for.*range.*:=.*{.*&[a-zA-Z_]' ./ --include='*.go'
重点关注：
-
&v出现在for range循环体内（尤其是赋值给全局/长生命周期变量） -
go func.*v.*()或func() { ... v ... }()类闭包调用 -
append或map操作中把&v当作 key/value 存储
这类代码不一定报错，但行为已变；不测试并发或指针比较，很难发现。
真正麻烦的不是改几行，而是有些逻辑隐含依赖“变量地址不变”这个未文档化特性——查的时候得看上下文，不能只盯单行。
