预分配容量可避免 append 频繁扩容导致的性能下降；Go slice 底层为数组，容量不足时 growslice 会分配更大数组并拷贝数据，引发 O(n) 均摊开销与内存抖动。
预分配容量是提升 append 性能最直接有效的方式，否则频繁扩容会触发多次底层数组复制。
为什么 append 会变慢？
Go 的 slice 底层是数组，当容量不足时，append 会调用 growslice 分配新数组（通常是旧容量的 1.25–2 倍），再把旧数据拷贝过去。这个过程在循环中反复发生，时间复杂度从 O(1) 退化为均摊 O(n)，且伴随内存抖动。
- 典型现象：
pprof显示大量runtime.makeslice或runtime.growslice调用 - 场景：批量解析 JSON、读取文件行、聚合数据库查询结果
- 关键点：不是
append本身慢，而是未预估长度导致反复 realloc
如何预分配？看 make 的三个参数
make([]T, len, cap) 中 cap 决定初始容量；只要最终长度 ≤ cap，整个追加过程零扩容。
- 已知确切长度（如固定大小批量）：
items := make([]int, 0, 1000) for i := 0; i < 1000; i++ { items = append(items, i) } - 长度可估算（如 HTTP header 数量通常
- 完全未知但有上限（如日志行数 ≤ 10w）：
logs := make([]string, 0, 100000) scanner := bufio.NewScanner(file) for scanner.Scan() { logs = append(logs, scanner.Text()) }
避免用 len 当 cap 初始化
写成 make([]T, 0, len(src)) 是常见误操作——它只保证容量够存当前数据，但若后续还要追加，依然会扩容。
立即学习“go语言免费学习笔记（深入）”；
- 错误示例：
src := []int{1,2,3} dst := make([]int, 0, len(src)) // cap=3 dst = append(dst, src...) // ok，len=3, cap=3 dst = append(dst, 99) // 触发扩容！因为 cap 已满 - 正确做法：按预期最大长度设
cap，或用copy+append组合：dst := make([]int, len(src)+1) copy(dst, src) dst[len(src)] = 99
- 性能影响：扩容时若原 slice 有 10MB 数据，每次复制就是 10MB 内存拷贝
特殊场景：复用切片避免反复分配
高频短生命周期切片（如网络包解析）适合复用底层数组，减少 GC 压力。
- 用指针传参 +
[:0]清空：func parsePacket(buf []byte, out *[]string) { *out = (*out)[:0] // 复用底层数组，不释放内存 // ... 解析逻辑，往 *out 追加 } var cache []string parsePacket(packet, &cache) - 注意：必须确保
cache不逃逸到长期作用域，否则阻碍 GC - 不适用场景：切片需跨 goroutine 传递、或长度波动极大（复用反而浪费内存）
真正影响性能的从来不是 append 函数调用本身，而是你有没有在分配时就告诉 Go “我大概要装多少东西”。容量预估偏差 20% 通常比每次都从 0 开始强得多。
