Go语言中利用bytes.Buffer预分配提升多段字符串写入效率

bytes.Buffer默认初始容量为0，小写入频繁触发翻倍扩容并拷贝数据，导致性能下降；预分配可避免多次realloc，但需合理估算长度，否则可能浪费内存或收益有限。

为什么直接写入 bytes.Buffer 有时反而慢？

因为默认初始容量只有 0，每次写入触发扩容时会重新分配底层数组并拷贝旧数据。尤其在已知最终长度（比如拼接固定模板+多个字段）时，反复扩容带来明显开销。

预分配不是“一定更快”，而是避免「多次小扩容」——关键看是否能提前估算总长度。

• 估算误差大（比如动态生成内容长度浮动超 ±50%）时，预分配收益有限，甚至因预留过多内存拖慢 GC
• 纯追加场景（WriteString / Write）有效；若中间穿插 Reset() 或读取 Bytes() 后再写，需重新评估
• bytes.Buffer 底层用 []byte，扩容策略是翻倍（类似 slice），所以 1KB → 2KB → 4KB 这类增长在高频小写入下很伤

怎么安全地预分配容量？

用 Grow() 或构造时传入初始 slice —— 两者语义不同：Grow(n) 保证至少能无扩容写入 n 字节，但不改变当前 len(buf)；而 bytes.Buffer{Buf: make([]byte, 0, cap)} 直接设定底层数组 cap。

推荐优先用 Grow()，它更符合「预估后留余量」的直觉，且不会意外污染已有内容：

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

• 先粗略计算所有待写字符串长度之和（含分隔符、换行等），再加 10%~20% 余量
• 调用 buf.Grow(totalEstimate)，之后所有 Write* 都不会触发扩容直到超出该值
• 如果已知精确长度且不追加新内容，用 bytes.Buffer{Buf: make([]byte, 0, exactLen)} 更省一次 Grow 内部判断

示例：

var buf bytes.Buffer
buf.Grow(len("name:") + len(name) + len(", age:") + len(strconv.Itoa(age)) + 2) // +2 for ", "
buf.WriteString("name:")
buf.WriteString(name)
buf.WriteString(", age:")
buf.WriteString(strconv.Itoa(age))

预分配后还踩哪些坑？

最常见的是误以为 Grow() 设置了「当前长度」——它只影响容量，buf.Len() 仍是 0，不会自动填充零值。

• 直接对 buf.Bytes() 做切片或修改，可能访问到未初始化的底层数组内存（虽然 Go 保证新分配 slice 为零值，但 Grow() 不触发清零）
• 在 Grow() 后调用 buf.Truncate(0)，容量不变但长度归零，下次写仍走预分配路径；但若先 Reset() 再 Grow()，效果一样
• 并发写入必须加锁，bytes.Buffer 非并发安全，预分配不改变这点
• 如果写入过程中 panic，已写的字节还在 buffer 里，但预分配的容量没释放——这不算 bug，只是要注意资源生命周期

比 bytes.Buffer 预分配更优的场景有哪些？

当拼接逻辑简单、片段数量少且长度确定时，fmt.Sprintf 或 strings.Join 可能更快，因为避免了对象分配和方法调用开销。

• 3~5 个字符串拼接，用 strings.Join([]string{a,b,c}, "") 通常比预分配 Buffer 更快
• 需要格式化（如 %d、%s）且变量少，fmt.Sprintf 的内部缓冲池有优化
• 大量重复拼接同一模板（如日志格式），建议预编译成函数或用 sync.Pool 复用 bytes.Buffer 实例，此时预分配才真正发挥价值

预分配本身很简单，难的是判断「什么时候值得做」以及「估多还是估少」——实际压测比理论推导更可靠。