Go Slice 和 Map 预分配：降低扩容与 rehash 成本

Slice 扩容和 map rehash 在小流量下不明显，但在批量接口、导出任务和高频聚合里会变成尾延迟来源。预分配不是微优化，而是让容量变得可解释。

容量来自输入规模

如果你已经知道结果上限，比如查询返回数量、批量 ID 长度或字段数量，就应该在 make 时给出容量提示。这样 append 不需要多次扩容复制。

Map 也需要容量

map 在增长过程中会触发 rehash。对批量构建索引、去重集合、分组统计来说，make(map[K]V, n) 能减少多次增长成本。

不要过度预分配

容量给太大也会浪费内存，尤其是在高并发请求中。建议按典型输入和最大输入分别压测，选择兼顾延迟和 RSS 的值。

生产场景

适用于批量查询、结果聚合、导入导出、去重和分组统计。

关键指标

• allocs/op、B/op
• append 扩容次数
• 大批量请求的 P99 和 RSS

常见误区

• 完全不估算容量
• 为了省一次扩容预分配巨大内存
• 忽略空输入和异常输入

代码示例

items := make([]Item, 0, len(ids))
index := make(map[int64]Item, len(rows))
for _, row := range rows { index[row.ID] = row }

上线检查

• 优化前后必须保留同一条件下的 benchmark 或 profile。
• 至少观察 P95/P99、错误率、CPU、内存和 GC 指标。
• 如果改动影响热路径，必须准备灰度和回滚方案。