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 值语义的自然体现。想绕过它，得主动选对类型（指针/切片）、用对方式（索引/键访问），而不是期待语法自动“传引用”。
