Go bytes.Buffer 和 strings.Builder 怎么选：字节写入、字符串拼接与复用差异

日志采集器里有一段代码，既要把请求头写成文本，又要把二进制摘要附在末尾。最初用一个字符串变量反复加号，压测时分配次数明显上升，改成缓冲后却又遇到“拿到的到底是字符串还是字节切片”的选择题。Go 里的 bytes.Buffer 和 strings.Builder 都能承接连续写入，但它们不是两个名字不同的同类工具：前者面向字节流，后者面向最终字符串。

先看结果要交给谁：字符串，还是字节流

选择之前先把调用链画小一点。模板渲染、日志字段和 SQL 片段通常要交给 string；压缩数据、HTTP 请求体、文件内容则经常要交给 []byte、io.Reader 或 io.Writer。结果类型一旦明确，候选方案其实已经去掉了一半。

两个候选方案各自擅长什么

strings.Builder：把连续文本拼成一个 string

strings.Builder 的设计目标很直接：通过 WriteString、WriteByte 等方法累积内容，最后调用 String() 得到字符串。它适合日志模板、路径、SQL 片段和 JSON 外壳这类“写进去，最后整体当文本使用”的场景。

var b strings.Builder
b.Grow(64)
b.WriteString("GET ")
b.WriteString(path)
b.WriteString(" status=")
b.WriteString(strconv.Itoa(status))
line := b.String()

Grow 不是必须调用的初始化步骤，只有能估算容量时才值得加。估小了仍会扩容，估大了则可能白占内存；不要为了“看起来专业”到处写一个很大的数字。

bytes.Buffer：文本和字节都能接

bytes.Buffer 更像一段可读写的内存字节流。它既能 WriteString，也能 Write 字节切片，还提供 Bytes()、Read 和 io.Reader 兼容能力。

var buf bytes.Buffer
buf.WriteString("header\n")
buf.Write(payload)
sendBody := buf.Bytes()
_ = sendBody

这里拿到的 Bytes() 是 Buffer 内部存储的视图。后续继续写入、调用 Reset 或让 Buffer 失去有效性后，不应继续依赖这段切片；如果下游需要独立持有，就明确复制。

同一段代码换工具，差别落在四个维度

如果下游马上调用 http.NewRequest 的字符串变体，Builder 的意图更清晰；如果下游函数签名是 io.Reader，Buffer 少一次中间转换，通常更顺手。这个结论是接口边界的选择，不是对任何输入都成立的性能承诺。

复用时最容易踩的坑：Reset 不是并发保护

在循环里复用缓冲可以减少临时对象，但复用前必须确认上一次结果已经消费完。最小的安全顺序是：读取或发送结果，结束本轮使用，再 Reset() 开始下一轮。

var buf bytes.Buffer
for _, item := range items {
    buf.Reset()
    buf.WriteString(item.Name)
    buf.WriteByte('\n')
    if _, err := dst.Write(buf.Bytes()); err != nil {
        return err
    }
}
return nil

不要把同一个 Builder 或 Buffer 放进多个 goroutine 共享，也不要在返回内部 Bytes() 后马上让另一个流程继续写。需要跨异步边界时，复制结果或为每个任务分配自己的缓冲。

不适用情况：别用缓冲器掩盖真正的问题

只有两三次短字符串拼接时，普通的 + 往往更容易读，也未必需要引入对象。需要按字段编码 JSON 时，应使用 encoding/json；需要格式化数字时，优先选择明确的格式化 API，而不是手工拼出可能转义错误的内容。缓冲器解决的是连续写入和结果承接，不是数据格式校验。

常见问题：bytes.Buffer 和 strings.Builder 怎么选

Builder 能不能拿到字节切片？

它的主要出口是 String()。如果调用方天然需要 []byte，直接使用 bytes.Buffer 通常更符合接口意图，避免为了类型再做一次转换。

Buffer.String() 和 Builder.String() 有什么本质区别？

两者都能生成字符串，但 Buffer 同时保留字节流读写能力；Builder 更专注于构建文本结果。应按后续接口选择，而不是只比较方法名。

调用 Reset 后容量会立刻归还吗？

不要把 Reset() 当作释放底层数组的保证。它适合清空逻辑内容并复用已分配空间；如果对象长期持有过大的缓冲，需要重新评估生命周期。

一张决策表：把选择落到调用链

• 只写文本，最后拿 string：选 strings.Builder。
• 要混合写文本和 []byte，或交给 io.Reader：选 bytes.Buffer。
• 要在循环中复用：先确认结果消费完成，再调用 Reset()。
• 只是少量拼接：先保留简单的 +，用基准测试证明复杂度值得。