bytes.Buffer 是 Go 中拼接大量字符串最稳妥的方案，因其避免重复内存分配与复制；小规模拼接（3–5 次）用 + 更简洁高效；因字符串不可变，+ 多次拼接导致 O(n²) 复制开销和频繁 GC。
直接说结论：bytes.Buffer 是 Go 中拼接大量字符串时最稳妥的方案，比 + 和 fmt.Sprintf 更快、内存更可控；但小规模拼接（比如 3–5 次）用 + 反而更简洁、无额外开销。
为什么不用 + 拼接大量字符串？
Go 的字符串是不可变的，每次 + 都会分配新内存并复制全部内容。拼接 n 次，总复制量接近 O(n²) —— 1000 次拼接可能触发几十次内存分配，GC 压力明显。
常见错误现象：for i := 0; i 在循环中累积拼接，CPU 和内存监控里能看到尖峰。
- 适用场景：拼接次数固定且极少（如
"prefix_" + name + "_suffix"） - 不适用场景：从文件/网络流式读取后逐段拼接、日志行组装、模板渲染输出
- 性能影响：字符串越长、次数越多，耗时增长越非线性
bytes.Buffer 怎么用才不踩坑？
核心是别忽略初始化容量。默认 Buffer 底层用 64 字节切片，频繁扩容会引发多次 append realloc，抵消优势。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 预估最终长度，用
bytes.NewBuffer(make([]byte, 0, estimatedSize))初始化 - 写入用
WriteString（比Write少一次类型转换），避免混用Write和.WriteString导致隐式拷贝 - 获取结果用
b.String()，不是string(b.Bytes())—— 后者会多一次底层数组复制 - 重用
Buffer时调用b.Reset()，别新建对象；但注意它不清除底层数组容量，所以后续写入仍高效
示例：
var buf bytes.Buffer
buf.Grow(1024) // 提前预留空间，比 NewBuffer 更明确
for _, s := range strs {
buf.WriteString(s)
}
result := buf.String() // 直接 String()，不 string(buf.Bytes())
strings.Builder 能替代 bytes.Buffer 吗？
能，而且更轻量——它是专为字符串拼接设计的，底层不支持读操作、不实现 io.Reader，因此少了字段和接口开销。
关键差异：
-
strings.Builder不允许读取中间状态（没Bytes()方法），只能最后调用String() - 它不允许并发写（
WriteString不是 goroutine-safe），这点和bytes.Buffer一致 - 如果拼接后还要做
bytes.NewReader或其他基于[]byte的操作，必须用bytes.Buffer - 性能上，
Builder略快（约 5–10%），但差异通常可忽略；优先选它，除非需要Bytes()或兼容旧代码
典型用法：
var b strings.Builder
b.Grow(1024)
for _, s := range strs {
b.WriteString(s)
}
result := b.String()
真正容易被忽略的是「预分配」和「重用」——很多人只记得用 Buffer 或 Builder，却在循环里每次都 new 一个，反而比 + 还慢；另外，String() 返回的是只读副本，如果后续还要频繁修改，得转回 []byte 处理，这时候 bytes.Buffer 的 Bytes() 就成了必要选择。
