go切片内部含隐藏指针指向底层数组，决定共享与修改行为；传参时副本的ptr仍指向原数组，故未扩容时修改元素会影响所有共享该数组的slice。
Go 中的切片本身不是指针，但它内部必然包含一个指向底层数组的指针——这个指针不暴露给开发者，却决定了几乎所有共享、修改和扩容行为。理解这点，就能避开 80% 的“为什么改了另一个 slice 也变了”类问题。
slice 传参时为什么能修改原数据
因为函数接收的是 slice 描述符的副本，而该副本中的 ptr 字段仍指向同一块底层数组。只要没触发扩容，所有通过 s[i] = x 的赋值都会反映到原始底层数组上。
- 修改元素（如
s[0] = 42）一定影响所有共享该底层数组的 slice -
append是否影响原 slice，取决于是否超出当前cap：未超则复用原数组；超了就分配新数组，指针更新，原 slice 不受影响 - 即使你写
func f(s []int) { s = append(s, 1); }，调用方的s也不会变——因为s是值传递，扩容后的新描述符只在函数内有效
*[]T 和 []*T 完全是两回事
前者是指向切片变量的指针（极少用），后者是元素为指针的切片（很常用）。混淆这两者是新手高频错误。
-
*[]int：用来让函数能替换整个切片头（比如重make或大范围append后想让调用方看到新地址），必须解引用才能操作：*p = append(*p, 1) -
[]*int：每个元素都是*int，适合避免复制大结构体、需原地修改字段的场景；注意循环中取址陷阱：for _, v := range data { ptrs = append(ptrs, &v) }会导致所有指针指向最后一个v的地址 - 绝大多数情况，你不需要
*[]T；直接传[]T或[]*T更清晰安全
如何判断或切断底层数组共享
没有标准库函数能直接告诉你两个 slice 是否共享底层数组，但你可以用 reflect.ValueOf(s).Pointer() 比较首地址——不过这只能说明“起点相同”，不能保证访问范围重叠。真正可靠的策略是主动隔离。
- 截取后要独立？用
append([]int{}, s[lo:hi]...)或copy+make - 返回局部 slice 给调用方？别返回
&s，直接返回s即可；Go 逃逸分析会自动把底层数组放到堆上 - 长期持有小 slice 却引用大数组？可能导致内存无法回收——比如从 1GB 日志里只取前 10 行，却一直拿着
logLines[:10]，整个 1GB 数组都活在内存里
最易被忽略的一点：共享不是 bug，是设计使然；问题出在“预期之外的共享”。与其纠结地址是否相同，不如在每次截取、传递、返回时，明确问自己一句：我是否希望它和原数据保持同步？答案为否，就立刻用 append 或 copy 切断关联。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
