修改 s[i] = x 会影响原 slice，因为传参拷贝的是 slice 头部（ptr、len、cap），ptr 指向同一底层数组，未扩容时所有共享该数组的 slice 修改元素均生效。
为什么修改 s[i] = x 会影响原 slice
因为传参时拷贝的是 slice 头部结构（ptr、len、cap），其中 ptr 是底层数组地址的副本。只要没扩容，所有共享该数组的 slice 都指向同一块内存，所以索引赋值直接写入原数组。
常见错误现象：在函数里把参数 slice 当“只读”用，却意外改了调用方数据；或以为加了 const 修饰就能防改（Go 没有 const slice 语义）。
- 安全场景：只读遍历、单点更新（如日志打点改状态位）
- 不安全场景：批量重写、条件覆盖、与并发 goroutine 共享同一 slice
- 判断是否共享：打印
&s[0]地址，多个变量地址一致即共享
append 后原 slice 不变的根本原因
append 不是“修改原 slice”，而是返回一个新 slice 值——它可能复用原底层数组（容量够），也可能分配新数组（容量不足）。但无论哪种，函数内局部变量的 ptr/len 字段已被重写，原始变量仍持旧值。
常见错误现象：“我明明写了 s = append(s, x)，为什么 main 里 len 还是老的？”——因为你改的是形参副本，不是实参本身。
- 扩容判断：调用前看
cap(s)，调用后对比&s[0]是否变化 - 零容量 slice（如
nil或make([]int, 0, 0)）必扩容，append总返回新头 - 性能提示：频繁
append且未预估容量，会反复 alloc/copy，比预分配慢 3–5 倍
什么时候必须返回 []T 并重新赋值
任何改变 slice “描述符三元组”（ptr、len、cap）的操作，都需显式返回并由调用方接收。这不是风格问题，是 Go 的值传递机制决定的刚性约束。
容易被忽略的边界操作：make 新建、s = s[i:j] 切片越界重赋值、s = append(s[:0], src...) 清空再填、甚至 s = s[:len(s):cap(s)] 重设容量。
- 正确模式：
s = grow(s)，函数签名必须是func grow(s []T) []T - 指针方案（
*[]T）不解决扩容后底层数组迁移问题，且破坏可读性，不推荐 - struct 封装仅在需要状态管理（如 ring buffer、pool）时值得引入，普通业务逻辑过度设计
copy 和直接赋值的本质区别
copy(dst, src) 复制元素值，不复制描述符；s2 := s1 复制描述符，不复制元素。前者产出两个独立底层数组，后者是同一数组的两个窗口。
常见错误现象：用 s2 := s1 做“备份”，结果改 s2 也改了 s1；或误以为 copy 会自动分配 dst 空间（它不会，dst 必须已存在且长度足够）。
-
copy返回实际拷贝元素数，等于min(len(dst), len(src)) - 想深拷贝 struct 字段里的 slice？得逐层
copy，或用json.Marshal/Unmarshal（注意性能） - nil slice 可作
dst吗？不行——copy对 nildst返回 0 且不 panic，但什么也不做
append 不透出）。真正关键的不是记结论，而是每次写函数前问自己一句：这次操作会不会改 ptr 或 len？答案为“是”，就必须返回。 
