Go切片扩容时拷贝不可避免，因新旧底层数组地址不同，必须memmove全部现有元素；拷贝成本取决于当前长度与元素大小，GC压力随之上升；预分配是唯一有效降低拷贝的手段。
扩容时 copy 是 unavoidable 的
只要触发 append 扩容，go 就必须执行一次完整的底层数组拷贝。这不是优化选项，而是语言机制决定的：新底层数组和旧数组物理地址不同，所有现存元素都得用 memmove 逐字节搬过去。哪怕你只加一个 int，也要拷贝前面全部数据。
- 拷贝成本 =
len(old_slice) × unsafe.Sizeof(element)，跟容量无关，只跟当前长度有关 - 如果元素是大结构体（比如含
[]byte或指针字段），拷贝的是值本身（非深拷贝），但内存带宽压力仍来自字节数量 - GC 压力会同步上升：旧底层数组变成不可达对象，等下一轮 GC 回收；高频扩容 → 频繁小对象分配 → GC 频次升高
扩容策略直接影响拷贝总次数和总字节数
Go 的分段扩容不是为了“省空间”，而是控制拷贝节奏。小 slice 翻倍，是为了摊薄摊销成本（amortized O(1)）；大 slice 改用 1.25 倍，是为了避免一次分配过大的内存块，同时减少后续拷贝总量。
- 从
cap=512扩到1024：一次拷贝 512 个元素 - 从
cap=2048扩到2560：一次拷贝 2048 个元素，但下次再扩只多 256 字节对齐增量，比翻倍（4096）少拷近一半数据 - 若预估最终长度为 3000，却用默认方式从空 slice 开始 append，实际会经历约 12 次扩容，累计拷贝超 15000 个元素（远超 3000）
哪些操作看似没扩容，其实偷偷拷贝了
有些写法你以为绕开了扩容，其实 runtime 内部仍会触发 growslice + memmove，只是你不显式看到 append 而已。
-
s = s[:len(s)+1]（越界伸长）：panic 前 runtime 会检查是否越 cap，若越就调growslice -
copy(dst, src)目标 dst 容量不足时不会自动扩容，但如果你事先make([]T, 0, n)再 copy，就完全规避了 append 类路径 - 从已有切片截取后追加：
sub := data[100:200]，若cap(sub) == 100，append(sub, x)会直接扩容，且新底层数组不再共享data，失去原数组局部性优势
真正有效的降拷贝手段只有预分配
别信“runtime 很聪明”——它只管单次 append 的最小开销，不管你的整个业务流程。唯一能砍掉拷贝的，是提前告诉 Go “我要多少”。
- 已知上限：用
make([]T, 0, estimated_max)，例如日志缓冲区预设make([]LogEntry, 0, 1024) - 有上下文长度：如 HTTP body 解析，header 已知长度为
n，直接make([]byte, 0, n+512)留余量 - 动态但可估：批量处理中，若每批次平均 200 条，按
256预分配，比盲目用make([]T, 0)少 90% 以上拷贝 - 别用
len(s) == cap(s)做运行时判断来手动扩容：这等于自己 reimplement growslice，还丢掉了对齐和分段逻辑
make 预分配，如果后续又做了 s = s[low:high] 截取，新切片的 cap 可能骤降，下一次 append 还是会触发拷贝——预分配的价值，只在原始切片生命周期内有效。 
