append触发扩容时必须拷贝原数据，因新旧底层数组地址不同，需memmove逐字节复制全部现有元素，时间复杂度O(len)，且该拷贝不可省略。
append 触发扩容时必须拷贝原数据
Go 的 append 不是“在原地加元素”，而是根据输入切片的 len 和 cap 做判断：当 len(s) + len(elements) > cap(s) 时，运行时会分配新底层数组，并用 memmove 把旧数组所有元素逐字节复制过去，再追加新元素。这个拷贝是强制的——不拷就丢数据。
- 哪怕只多追加 1 个元素，只要容量不够，就得整块搬
- 拷贝开销与当前
len(s)成正比，不是常数时间 - 新数组容量通常按策略翻倍（如小容量翻 2 倍，大容量增长更保守），但旧数据一次都不能少
为什么 append(s[:0:0], s) 总是深拷贝
写法 append(s[:0:0], s) 是一种常见克隆惯用法，它的效果等价于 copy，但背后机制很明确：
-
s[:0:0]构造出一个长度为 0、容量为 0 的切片，指向原底层数组起始地址但“不可见”任何元素 - 传给
append作第一个参数时，因cap == 0，必然触发扩容 → 分配新数组 - 第二个参数
s的全部元素被追加进这个新数组，完成物理隔离 - 注意：
s[:0:0]本身不改变原切片，也不释放内存；只是让append别无选择只能新建
不扩容时反而更危险：静默共享底层数组
很多人以为“没拷贝就是快”，但在 Go 里，append 容量充足时不拷贝，恰恰是 bug 温床：
- 多个切片变量（如
a,b,c）若都基于同一个高容量切片反复append，它们底层指向同一块内存 - 后续对任一切片的写操作（比如
a[0] = 999）会直接改掉b[0]和c[0]的值 - 这种覆盖没有编译错误、不 panic，只在运行时逻辑错乱，极难定位
- 典型场景：循环中复用一个
make([]int, 0, N)作为 append 起点
真正可控的复制方式只有两种
想确保副本独立，不能依赖 append 的行为猜测，必须显式控制：
- 用
make+copy：最直白，语义清晰c := make([]T, len(s)); copy(c, s) - 用
append(s[:0:0], s...)：一行搞定，但需理解其强制扩容逻辑 - 避免踩坑的关键是：永远不要把
append当成“修改原切片”的操作；它返回新切片头，而是否复用底层数组，完全由cap决定——这个决定发生在运行时，且对调用者不可见
