因为切片传参复制结构体，append未扩容时复用原底层数组，修改会反映到外部；扩容则返回新地址，外部不受影响。
为什么 append 会悄悄改掉外面的切片？
因为切片底层是 struct{ ptr *T, len, cap int }，传参时复制的是这个结构体——指针、长度、容量都拷贝了一份。只要没触发扩容，ptr 指向同一块底层数组，append 写进去的数据就直接落到了原数组上。
常见错误现象：func modify(s []int) { s = append(s, 99) } 调用后外部切片“好像”没变；但换成 s[0] = 123 或 s = append(s[:1], 42) 就可能意外生效——取决于是否复用原底层数组。
- 扩容时
append返回新地址，原切片不受影响 - 不扩容时（
len ），修改 <code>s[i]或用append填充空位，都会污染外部数据 - 别依赖“看起来没变”，要明确知道当前操作是否复用底层数组
如何让函数内操作完全隔离外部切片？
核心思路：切断底层数组引用。不是“避免修改”，而是“确保不共享”。最可靠的方式是创建新底层数组并拷贝内容。
- 需要新切片且内容无关时，用
make([]T, len(s), cap(s))+copy：newS := make([]int, len(s)) copy(newS, s)
- 只读场景可直接传
[]T，但函数内禁止任何写操作（包括append和索引赋值） - 如果只是临时扩展，又不想影响调用方，先判断是否要扩容：
if len(s) == cap(s) { s = append(s[:0], s...) }强制复制
append 的行为和 cap 关系有多大？
cap 是决定“是否扩容”的唯一开关。它不保证安全，只决定内存分配时机。很多坑就出在误以为 cap 大=安全，其实只要没重新分配，就还在原数组上。
- 即使
cap很大，s[0] = x仍会改原数组 -
append(s, x)是否扩容，看len(s) ；但 <code>append(s[:n], x)的cap可能比原切片小，更容易扩容 - 用
fmt.Printf("len=%d cap=%d ptr=%p", len(s), cap(s), &s[0])打印对比，能快速验证是否共享底层数组
哪些场景必须手动深拷贝切片？
当函数职责是“接收数据、加工、返回新结果”，且调用方后续还要继续用原始数据时——不能假设对方不会接着读或写原切片。
- HTTP handler 解析请求 body 切片后做校验/转换，再存入 DB 或转发，必须隔离
- 并发 goroutine 处理同一个切片的不同子段，哪怕只读，也要注意
range迭代时的隐式共享（range中的v是副本，但&v不是） - 单元测试中反复传同一测试切片给多个函数，一个函数里的
append可能让后续测试失败
真正麻烦的不是拷贝本身，而是有些地方你根本没意识到自己正在共享底层数组——比如从 map 取值、从 channel 接收、甚至用 s[:] 做切片重切，都可能延续原指针。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
