预分配容量可避免多次底层数组复制，显著降低拷贝开销和内存分配次数；make([]T, 0, N)中0为初始长度、N为容量，应按实际需求合理预估而非盲目设大。

预分配容量能避免多次底层数组复制

Go 的 append 在容量不足时会触发扩容：分配新数组、拷贝旧数据、释放旧内存。这个过程不是“加一个元素就扩一次”，而是按策略放大——cap 时翻倍，≥1024 时约增长 25%。这意味着从空切片追加 1000 个元素，可能经历 10+ 次扩容，产生 O(n²) 级别的数据拷贝开销。

• 不预分配：var s []int → 每次 append 都可能触发扩容 + 复制
• 预分配：s := make([]int, 0, 1000) → 所有 append 都在原底层数组内完成，零拷贝
• 实测显示：处理千级元素时，预分配版本 B/op（每操作字节数）和 allocs/op（分配次数）可降低 90% 以上

make([]T, 0, N) 中的 0 和 N 含义常被混淆

很多人误以为第三个参数是“初始长度”，其实它是容量（cap），而第二个参数才是长度（len）。写成 make([]int, 1000) 会直接初始化 1000 个零值元素，长度和容量都是 1000；但多数场景你只需要“预留空间”，并不需要这些初始值。

• ✅ 正确（推荐）：s := make([]int, 0, 1000) —— 长度 0，容量 1000，append 安全填充
• ❌ 错误（浪费）：s := make([]int, 1000) —— 长度=容量=1000，且已写入 1000 个 0，后续还要覆盖
• ⚠️ 危险：s := make([]int, 1000, 1000) —— 表面看没问题，但若你本意是“收集最多 1000 个”，却误用 len 初始化，逻辑易错且内存冗余

哪些场景必须预分配？哪些可以偷懒？

预分配不是银弹，关键看是否「可预估」且「高频发生」。小规模、一次性、长度极不确定的操作，预分配收益低甚至增加心智负担。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• ✅ 必须预分配：
  – 读取文件行数可估算（如日志解析，单文件 ≤ 5000 行）
  – 合并多个已知大小的切片（totalCap := len(a) + len(b) + len(c)）
  – HTTP handler 中构建固定结构响应（如 []User，用户列表页通常限 20/50/100 条）
• ❌ 可暂不预分配：
  – 用户输入动态拼接（如命令行参数解析，长度完全不可控）
  – 临时调试打印，生命周期仅几行代码
  – 切片只读、不 append（如传参用 s[10:20]）

sync.Pool 复用切片比预分配更进一步

当切片在高频短生命周期场景反复创建（如每个 HTTP 请求都新建 []byte 缓冲区），即使每次预分配，仍会造成 GC 压力。这时应考虑 sync.Pool 复用底层数组。

立即学习“go语言免费学习笔记（深入）”；

• 池化示例：

  var byteSlicePool = sync.Pool{
      New: func() interface{} {
          return make([]byte, 0, 1024)
      }
  }
  // 使用
  buf := byteSlicePool.Get().([]byte)
  buf = buf[:0] // 清空长度，保留底层数组
  // ... 填充数据
  byteSlicePool.Put(buf)

• 注意点：
  – Put 前确保不再访问该切片，否则可能引发 data race
  – 池中对象大小应相对稳定，过大（如 MB 级）反而加重 GC
  – 不适用于跨 goroutine 长期持有，仅适合“用完即还”的瞬时缓冲

预分配本身很简单，但真正难的是判断“什么时候该预”、以及“预多少才不浪费”。很多性能问题不是没预分配，而是预得太多（比如总长 100 却预 10000）或复用不当（比如把池里切片传给异步 goroutine）。记住：容量是契约，不是许愿池。