Go 1.22起，for循环变量（含range中的v和普通for中的i）每次迭代均创建新变量，不再复用同一内存地址。
Go 1.22 起，for 循环变量（包括 for _, v := range 中的 v 和 for i := 0; i 中的 <code>i）每次迭代都创建新变量，不再复用同一内存地址——这不是优化，是语义变更，直接影响闭包、goroutine、指针取址行为。
为什么 go func() { fmt.Println(v) }() 在 Go 1.22 下“突然正常”了？
不是它变对了，而是变量绑定逻辑变了：旧版中所有 goroutine 共享一个 v 地址，最后值覆盖为末尾元素；新版中每个迭代的 v 是独立变量，闭包捕获的是各自迭代时的值。
但别因此放松警惕——这种“正确”只在值类型且不涉及地址传递时成立。一旦你写 &v 或把 v 当作结构体字段初始化，行为就完全不同了：
-
for _, v := range items { ptrs = append(ptrs, &v) }：Go 1.21 中ptrs所有元素指向同一地址；Go 1.22 中指向不同地址，但所有地址都指向最后一次迭代后仍存活的v实例（因为循环变量生命周期延伸到整个循环结束） - 若
items是[]*int，v是指针，那&v拿到的是指针变量本身的地址，不是它指向的目标——这点在两个版本里都没变，但容易混淆
for i := range 10 是什么鬼？它和变量语义变更有关吗？
无关。for i := range 10 是 Go 1.22 新增的语法糖，等价于 for i := 0; i ，仅适用于正整数常量或变量。它不触发“每轮新建变量”的机制——因为这里 <code>i 本就是经典 for 的初始化变量，而该机制已统一覆盖所有 for 形式（包括 range 和传统 for）。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正要注意的是：这个新语法返回的是索引（0 到 9），不提供值，也不能用于 map/string/channel。误以为它能遍历 map 键或字符串 rune，纯属混淆。
哪些代码必须 grep 检查，否则上线就出问题？
重点搜这三类模式，它们在 Go 1.22 下行为突变最隐蔽：
-
for _, v := range x { go func() { use(v) }() }：看似“修好了”，但如果use内部做了&v或传给其他长期存活对象，结果可能错得更难定位 -
for _, v := range x { defer fn(&v) }：Go 1.21 中所有defer调用看到的是同一个&v；Go 1.22 中每个defer拿到不同地址，但所有地址最终都解引用到循环结束时的v值（即最后一个） -
for i, v := range s { m[&v] = i }：map key 变成多个地址，但 value 全是最后一个i，且&v的有效性依赖逃逸分析——可能栈上分配，循环一结束就悬空
想兼容旧版“变量复用”效果，该怎么写？
不能靠降级 Go 版本，也不能用 for i := range items { v := items[i] }——这行代码在 Go 1.22 下 v 仍是每轮新建，和 range 写法无区别。
真需要地址稳定，唯一可靠方式是显式控制存储位置：
- 用切片预分配：
vs := make([]T, len(items)); for i, item := range items { vs[i] = item; ptr := &vs[i]; ... } - 用局部作用域重声明（仅限简单场景）：
for _, v := range items { v := v; go func() { fmt.Println(&v) }() }——此时&v指向的是该次迭代内声明的新变量，生命周期与该 goroutine 对齐，但要注意逃逸成本
最易被忽略的点：循环变量的“新建”不等于“堆分配”。编译器仍会做逃逸分析，&v 是否上堆取决于后续使用方式，而非是否新建——这点在排查内存泄漏或 GC 压力时经常被误判。
