Golang for-range循环的副本机制_遍历数组/切片时的值拷贝

for-range遍历切片时v是值副本，修改无效；应通过s[i]修改；指针切片中*v可改原值；map遍历时v也是副本且顺序不保证，需用m[k]修改。

for-range 遍历切片时，v 是副本，改它没用

go 的 for range 遍历切片（或数组）时，每次迭代的第二个变量（比如 v）是元素的**值拷贝**，不是原底层数组的引用。直接修改 v 不会影响原切片。

常见错误现象：v = 99 后打印原切片，发现值完全没变；或者在循环里把 v 传给 goroutine，结果所有 goroutine 都看到最后一个值（因为 v 是复用的栈变量，且被不断覆盖）。

• 正确做法：用索引访问并修改 —— s[i] = 99
• 如果真要操作副本再写回，得显式赋值：s[i] = v * 2
• 传入 goroutine 时，必须传 s[i] 或 i，而不是 v（否则闭包捕获的是同一个地址）

遍历指针切片时，v 是指针副本，但解引用后能改原数据

如果切片类型是 []*int，那 v 是指针的副本 —— 指针值本身被拷贝了，但它指向的内存地址没变。所以 *v = 42 是有效的，会修改原始 int 值。

使用场景：批量更新结构体字段、重置对象状态等，前提是切片里存的是指针。

立即学习“go语言免费学习笔记（深入）”；

• v 仍是副本，但它是“指向同一块内存的另一个指针”，不是深拷贝
• 如果做 v = nil，只清空副本，不影响原切片里的指针
• 性能上无额外分配，但要注意空指针 panic：遍历前确认 v != nil

range 遍历 map 时，v 也是副本，且顺序不保证

map 的 for range 同样拷贝 value，改 v 对原 map 无效；而且 Go 运行时会随机化遍历起始位置，每次运行顺序都可能不同。

容易踩的坑：依赖 map 遍历顺序做逻辑判断（比如取第一个非零值），或在循环里反复修改 v 以为能累积效果。

• 要修改 map 元素，必须用 m[k] = newV
• 需要稳定顺序？先取 keys := maps.Keys(m)（Go 1.21+），再 sort.Strings(keys)，最后按 key 遍历
• 并发读写 map 会 panic，哪怕只是 range + 读 —— 必须加 sync.RWMutex 或改用 sync.Map

数组和切片的 range 行为一致，但底层复制成本不同

对数组（如 [3]int）做 for range，v 是整个数组元素的拷贝；对切片（[]int），v 是单个元素的拷贝。看起来一样，但误用大数组时，性能差异明显。

比如遍历 [10000]int，每次迭代都拷贝 10000 个 int（80KB），而切片只是拷贝一个 int（8 字节）。

• 大数组尽量用索引遍历：for i := range arr { ... arr[i] ... }
• 函数参数接收大数组时，优先用指针：func f(a *[10000]int)，避免调用时整块拷贝
• 切片没有这个问题，因为 len/cap/ptr 三元组本身很小（24 字节）

最常被忽略的一点：for range 的副本机制不是 bug，是 Go 值语义的自然体现。想绕过它，得主动选对类型（指针/切片）、用对方式（索引/键访问），而不是期待语法自动“传引用”。