修改s[0]=100生效是因为切片副本的ptr指向原底层数组，而append不生效是因为它返回新切片但未被赋值回原变量；必须显式s=f(s)才能更新原始切片。
为什么修改 s[0] = 100 生效，但 append(s, x) 不生效
因为切片本身是值传递：传入函数的是一个含 ptr、len、cap 的结构体副本。副本里的 ptr 和原切片指向同一底层数组，所以通过索引赋值（如 s[0] = 100）会直接改写原数组内存，调用方可见；但 append 是纯函数式操作——它不修改旧切片，只返回新切片。如果函数内没把返回值赋给参数变量，也没返回给调用方，那所有 append 结果都只是临时副本，作用域一结束就丢弃。
-
append是否触发扩容不影响“是否生效”，只影响“是否还共享底层数组”：容量够时复用原数组，改写可能意外污染其他切片；容量不够时分配新数组，原切片彻底“断连” - 调试时可打印
uintptr(unsafe.Pointer(&s[0]))看地址是否变化（仅限调试，勿进生产） - 常见误写：
append(s, x)单独一行，没接返回值 → 完全无效
如何让 append 的结果真正更新原始切片
必须显式返回新切片，并由调用方重新赋值。Go 没有引用传参语法糖，这是约定俗成的模式，不是缺陷。
- 函数签名应为
func f(s []T) []T，末尾return append(s, x) - 调用方必须写成
s = f(s)，漏掉s =就等于没调用 - 若函数内多次
append，统一在最后return一次最安全，避免中间状态被误用 - 传
*[]T虽技术可行，但违背 Go 习惯，且易引发解引用错误，不推荐
哪些场景下容易忽略切片共享底层数组的风险
当多个切片来自同一数组或同一 make 分配的底层数组时，它们实际共享内存——这在结构体字段、map value、slice 元素中尤其隐蔽。
- 结构体字段是切片？复制该结构体后，两个实例的切片字段仍指向同一底层数组
- 把切片存进
map[string][]int后反复append，可能意外覆盖其他 key 对应的切片数据 - 用
s[i:j]切出子切片再传入函数，该子切片和原切片共享底层数组，append可能覆写原数组未被切片覆盖的区域 - 预分配容量可降低风险：
make([]T, 0, estimatedCap)减少意外扩容，但不能消除共享
什么时候该用 copy 而不是直接传切片
当你需要函数内修改不影响调用方的原始数据，且不关心扩容逻辑时，copy 是轻量级隔离方案。
立即学习“go语言免费学习笔记（深入）”；
- 先
dst := make([]T, len(src))，再copy(dst, src)→ 得到独立副本 -
copy按最小长度拷贝，所以目标切片长度必须 ≥ 源切片长度，否则丢数据 - 注意：
copy不解决深层嵌套结构（如[]*struct{}中的指针所指对象），仅隔离 slice 本身 - 性能敏感场景慎用：大 slice 的
copy有内存拷贝开销，比共享底层数组慢
append、每一次切片操作、每一次结构体赋值，都在悄悄复制那个三元结构体——而你永远不知道哪一次复制会让底层数组突然“分裂”。 
