预分配容量可将扩容次数从多次降至零次，如100万个元素时未预分配发生18次扩容，预分配后为0次。
预分配容量能避免多少次扩容
预分配容量不是“锦上添花”，而是直接决定 append 是否触发 runtime.growslice。不预分配时，[]int{} 初始 cap=0，第一次 append 就要分配新底层数组；而 make([]int, 0, N) 让前 N 次 append 全部落在原数组内，零拷贝、零重分配。
常见错误现象：pprof 显示 runtime.growslice 占 CPU 热点 top 3，或 GC 压力突增——大概率是未预估容量的 slice 在高频追加。
- 小数据量（
- 容量预估偏大（比如
make([]byte, 0, 1）会浪费内存，尤其在短期局部变量中 - 若长度无法精确预估，可按典型值+20%富余（如日志条目平均 150 条/用户 → 预设 cap=180）
cap
Go 的 growslice 并非简单翻倍：当当前 cap < 1024，新 cap 直接设为 oldcap * 2；当 oldcap >= 1024，则按 oldcap + oldcap/4 增长（即 1.25 倍）。这个阈值和增幅都写死在 src/runtime/slice.go 中。
这意味着：从 cap=1023 扩容一次就跳到 2046，但 cap=1024 扩容后只到 1280——后者更省内存，但扩容次数更多。实际影响取决于你追加的总元素数是否跨过多个 1.25 倍区间。
- 对大 slice（如缓存 >1MB 的二进制块），别迷信“翻倍更快”，1.25 倍反而降低峰值内存占用
- 元素类型大小会影响对齐策略，
growslice内部调用roundupsize向最近的内存块对齐，所以偶数 cap 不一定比奇数 cap 更省空间 - 用
unsafe.Sizeof测过元素大小后，可粗略估算真实内存开销，比只看 cap 数字更准
append 多个元素时的底层开销
append(s, x, y, z) 和三次单元素 append 行为完全不同：前者在一次扩容判断后批量复制，后者可能触发多次扩容+多次 copy。尤其当初始 cap 刚好卡在临界点（如 cap=3，追加 4 个元素），单次多参数 append 可避免中间态扩容。
典型错误写法：for _, v := range items { s = append(s, v) } ——即使预分配了 cap，循环内每次仍要检查 len/cap 关系、计算地址偏移，CPU 分支预测失败率上升。
- 优先用
append(s, items...)替代循环追加，前提是items是切片且长度已知 - 如果
items是接口或需转换（如string转[]byte），先批量转换再append(...)，别在循环里做类型转换 - 注意
...展开有栈空间成本，超大切片（>64KB）展开可能引发栈溢出，此时应分块append
底层数组复用与意外共享的边界
Go 运行时在扩容时会尝试复用原底层数组——仅当该数组引用计数为 1（即只有当前 slice 指向它）时才复用。一旦存在其他 slice 共享同一底层数组（如通过 s[2:5] 截取），扩容必然分配新数组。
这导致一个隐蔽问题：你以为预分配了 cap=1000，但上游传来的 slice 是从更大数组截取的（如 big[100:200:1000]），它的 cap 实际是 900，append 仍会立即扩容并复制全部 100 个元素。
- 用
cap(s)和len(s)不能反推底层数组总大小，只能知道“从 s 起始位置往后还能塞多少” - 接收外部 slice 参数时，若后续要大量
append，建议显式拷贝：s = append([]T(nil), s...)或copy(make([]T, len(s)), s) - 调试时可用
unsafe.Pointer(&s[0])对比不同 slice 的底层数组地址，确认是否真共享
预分配不是万能解药，真正关键的是理解：每次 append 都在跟运行时协商内存，而协商结果取决于你传进去的 cap、当前 len、元素类型，以及那一刻底层数组的引用状态。
