预分配容量可避免多次底层数组复制，显著降低拷贝开销和内存分配次数；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初始化，逻辑易错且内存冗余
哪些场景必须预分配？哪些可以偷懒？
预分配不是银弹，关键看是否「可预估」且「高频发生」。小规模、一次性、长度极不确定的操作，预分配收益低甚至增加心智负担。
- ✅ 必须预分配：
– 读取文件行数可估算（如日志解析，单文件 ≤ 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）。记住：容量是契约，不是许愿池。