&v 总是指向循环变量副本的栈地址，而非原切片元素；修改 *p 不影响原数据，因 v 是独立局部变量，生命周期仅限当轮迭代。
for range 遍历中对元素取地址（&v）得到的指针，永远指向栈上副本，不是原 slice 底层数组里的元素——扩容与否完全不影响这个行为。
为什么 &v 总是“无效”的指针？
Go 的 for range 对 slice 遍历时，每次迭代都会把当前元素**复制一份到循环变量 v 中**，v 是独立的局部变量，生命周期仅限本轮循环。因此 &v 拿到的是这个临时副本的地址，不是底层数组里那个真实元素的地址。
常见错误现象：
- 存一堆 &v 到 map 或切片里，最后发现所有指针都指向同一个内存位置（其实是最后一轮的 v 副本）；
- 修改 *ptr 后，原 slice 元素没变；
- 以为扩容后 &v 会失效，其实它本来就不指向原数据。
- 无论是否触发
append扩容，v始终是副本，&v始终是栈地址 - 即使原 slice 底层数组被迁移（扩容导致新分配），
v的值在循环开始前就已确定，不受影响 - 想拿到真实元素地址，必须用索引：&s[i]，且确保
s未被扩容覆盖（或确认未共享底层数组）
什么时候 &s[i] 会因扩容失效？
直接对 slice 索引取地址（&s[i]）是安全的，但前提是该地址在后续使用时，s 的底层数组**没有被替换**。一旦发生扩容，s 的 array 字段会指向新内存，旧地址变成悬垂指针（dangling pointer）。
典型陷阱场景：
- 在循环内先存下 &s[0]，再执行 s = append(s, x) 且触发扩容 → 后续解引用 *ptr 读到的是旧内存垃圾或 panic（取决于 GC 状态）；
- 多个 goroutine 同时读写 s 并取地址 → 竞态 + 悬垂风险叠加。
- 扩容后
&s[i]的有效性只依赖于你是否还持有对旧底层数组的其他引用（如另一个未扩容的切片） - 如果只有
s一个变量引用该数组，扩容后旧地址立即不可靠 - 用
unsafe.Slice(&s[0], len(s))这类操作前，必须确保s不会在别处被扩容
如何安全地在遍历中获取可长期使用的元素指针？
没有银弹，但有明确路径：避免依赖 slice 动态性带来的地址稳定性。核心原则是——**把“需要指针”的逻辑和“可能扩容”的逻辑拆开**。
- 若需修改原 slice 元素，直接用索引赋值：
s[i] = newValue，不取地址 - 若需传递指针给其他函数，且该函数生命周期长于当前 slice，先深拷贝元素：
ptr := &struct{...}{s[i]}（值拷贝后取址） - 若必须共享底层数组地址，提前预分配并禁止扩容：
s := make([]T, N); for i := range s { use(&s[i]) } - 对结构体切片，更推荐用索引+字段访问（
s[i].Field）而非取整个结构体地址，减少误用风险
最易被忽略的一点：很多人以为“只要没扩容，&s[i] 就永远安全”，但忘了 s = s[1:] 或 s = s[:len(s)-1] 这类操作虽不扩容，却会改变 s[0] 对应的底层数组偏移——此时 &s[0] 地址变了，但旧指针仍指向原位置，同样悬垂。
