append触发的memmove开销等于len(old_slice)×unsafe.Sizeof(element)，与cap无关；如[]int64长度10万时单次扩容搬800KB，大结构体切片更甚，pprof中memmove占比突增、GC变慢即为此因。
append 触发的 memmove 开销到底有多大
拷贝成本不是凭感觉估的，它等于 len(old_slice) × unsafe.Sizeof(element)，和容量无关，只跟当前长度有关。一个 []int64 切片长度为 10 万，单次扩容就要搬 800KB；如果是 []struct{a, b, c [1024]byte}，一次拷贝就超 3MB。
常见错误现象：pprof 中 runtime.memmove 占比突增、GC mark 阶段变长、gctrace 显示每秒 alloc 数量远超业务逻辑实际创建的对象数。
- 小 slice（
cap < 1024）翻倍扩容，前几次便宜，但第 10 次可能已拷贝超 500 个元素 - 大 slice（
cap >= 1024）按 1.25 倍增长，看似温和，但一次扩从 2048→2560，仍要拷贝全部 2048 个元素 - 哪怕只
append一个int，只要触发扩容，就得搬前面所有数据——这不是优化开关，是语言机制决定的
make([]T, 0, N) 和 make([]T, N) 的内存行为差异
两者分配行为完全不同：make([]int, 0, 1000) 只分配底层数组、不写零值；make([]int, 1000) 会初始化 1000 个 0，还把 len 设成 1000，后续 append 很可能立刻触发扩容（因 len == cap）。
使用场景上，如果你明确要往里面 append 数据，几乎总是该选前者。后者适合需要随机索引赋值、且初始长度就固定的情形。
立即学习“go语言免费学习笔记（深入）”；
-
make([]byte, 0, n)是 HTTP body 解析、日志缓冲等场景的标准写法 - 误用
make([]string, n)会导致 n 个空字符串被初始化，浪费内存且增加 GC 扫描负担 - 结构体切片尤其危险：
make([]User, 0, 1000)分配 1000 个结构体空间但不初始化字段；make([]User, 1000)会把每个User{}写进内存，开销翻倍
哪些写法看似绕开了 append，其实照样拷贝
别被表象骗了——只要最终导致底层数组地址变更，就逃不掉 memmove。runtime 不关心你怎么写，只看 len == cap 是否成立。
典型伪优化：
-
s = s[:len(s)+1]：越界 panic 前，runtime 仍会检查是否超cap，超了就调growslice -
sub := data[100:200]后append(sub, x)：若cap(sub) == 100，扩容后新底层数组脱离data，失去共享优势，且拷贝的是sub全部内容 -
copy(dst, src)目标dst容量不足时不会自动扩容，但如果你没提前make足够空间，下一次append还是得拷
真正省拷贝的唯一路径，是让 len(s) < cap(s) 在整个生命周期内始终成立。
预分配容量不是猜大小，而是控节奏
预分配不是“越大越好”，也不是“差不多就行”。它是用确定性换掉不可控的指数级拷贝累积。
例如处理数据库 LIMIT 1000 查询结果，用 make([]Row, 0, 1000) 可确保最多一次分配、零次扩容；而从空 slice 开始 append，实际会经历约 10 次扩容，累计拷贝超 1500 个元素（远超 1000）。
- 已知上限：直接用
make([]T, 0, exact_max)，如解析 header 最多 100 个，就设cap=128 - 无法精确但可估：取均值 × 1.5 并向上取整到 2 的幂（如平均 200 条 →
cap=256） - 注意类型大小影响：
[]string拷贝的是指针（8 字节），[][1024]byte拷贝的是整块内存，差两个数量级
最常被忽略的一点：预分配后若中间有 goroutine 或 map 持有了原底层数组的其他 slice，Go 就不敢复用底层数组——哪怕你 cap 还很富裕，也会被迫新建。验证方式很简单：fmt.Printf("%p", &s[0])，扩容前后地址变了，就是被引用污染了。
