strings.Builder 组装大文本并减少临时分配的方法

当一段文本由很多行、字段或循环片段组成时，连续使用 result += part 很容易让代码看起来简单，却把中间字符串的复制和重新分配藏在循环里。更稳妥的做法是让 strings.Builder 持有一次组装过程的写入缓冲区，最后只调用一次 String() 得到结果。

官方地址：https://pkg.go.dev/strings#Builder

零值 Builder 可以直接使用；大文本场景优先采用 Write 系列方法，能估算总字节数时再调用 Grow，Builder 不要复制，也不要在多个 goroutine 间共享同一个实例。

先把拼接问题拆成输入、缓冲区和结果

我通常先把组装任务分成三块：循环里不断到来的片段、负责承接片段的可增长缓冲区，以及最后交给 HTTP 响应或文件写入的完整字符串。普通的 += 把“追加一个片段”和“生成新的字符串”绑在一起；片段变多时，旧内容可能被反复搬运。

Builder 的重点不是让每一次写入都变成神奇的零分配，而是把多次写入集中到一个专门的缓冲对象中。它适合模板片段、日志摘要、导出文本和协议正文这类“先在内存中组装，再整体交付”的场景；如果结果本来就应该直接流向网络或文件，则应优先考虑 io.Writer，不要为了使用 Builder 强行把全部内容留在内存中。

用 Write 系列方法组装大文本

零值 Builder 不需要构造函数。字符串直接使用 WriteString，单字节分隔符使用 WriteByte，整数先用 strconv.AppendInt 写入临时字节片段或使用格式化函数时要注意额外分配。下面的例子保持逻辑简单，重点是写入方向和错误边界。

package main

import (
    "fmt"
    "strconv"
    "strings"
)

func buildReport(items []string) string {
    var b strings.Builder

    // 这是保守的字节容量估算，不把字符数误当成字节数。
    b.Grow(len(items) * 32)
    b.WriteString("items:\n")

    for i, item := range items {
        // 先写固定结构，再写动态字段，避免整行反复拼接。
        b.WriteString("  - ")
        b.WriteString(strconv.Itoa(i + 1))
        b.WriteString(": ")
        b.WriteString(item)
        b.WriteByte('\n')
    }

    // String 只在交付结果时调用一次。
    return b.String()
}

func main() {
    fmt.Print(buildReport([]string{"alpha", "beta", "gamma"}))
}

这里忽略了 WriteString 返回的错误，是因为 Builder 的文档约定这些写入方法返回成功；如果把 Builder 换成可能失败的外部 Writer，就不能沿用这个假设。WriteRune 适合明确拿到 rune 的场景，写入的是该 Unicode code point 的 UTF-8 编码。

Grow 要按字节估算，别把容量预测写死

Grow(n) 的含义是：调用后，至少保证还能写入 n 个字节而不再因为容量不足触发分配。它不是“最终结果一定正好 n 字节”，也不是字符数量接口。英文、数字和标点的估算通常较直观；中文等 UTF-8 文本如果只按 rune 数估算，容易低估所需字节数。

上面的 len(items) * 32 只是示例中的保守起点。真实代码可以根据固定前缀、分隔符、序号长度和字段平均长度建立估算；如果输入长度变化很大，宁愿给出温和的估算，也不要为了一个极小的理论误差把内存一次性扩得过大。

复用和并发边界要先说清楚

短生命周期函数里用局部 Builder 最省心。需要在同一对象内多次组装时，可以在交付旧结果后调用 Reset 清空 Builder，再写入下一份内容；但复用会保留底层容量的生命周期影响，面对一次特别大的请求时，要评估它是否会让对象长期占着过大的缓冲区。

还有两个容易被忽略的边界：第一，非零 Builder 不应复制，所以不要把它作为值随意塞进结构体、赋值给另一个变量或跨函数复制；第二，同一个 Builder 不应被多个 goroutine 同时写入。工程上更常见的做法是“一个请求或一个组装任务一个 Builder”，需要并发时让每个任务拥有自己的实例。

如果要确认优化是否值得，准备相同输入的两个 benchmark：一个用 +=，一个用 Builder；同时观察输出是否一致、-benchmem 下的分配变化以及输入规模增大后的趋势。不要把一次本地小输入的数字直接当成所有生产流量的结论。

常见问题

Builder 能不能直接返回给另一个函数继续写？

可以传递指针并由同一个生命周期负责写入，但要避免复制非零 Builder，也要把“谁负责最终 String、谁负责 Reset”约定清楚。

Grow 调得越大越好吗？

不是。Grow 只应基于可解释的字节估算；过大的预留会增加内存占用，输入波动明显时应保持估算保守。

Builder 能替代所有字符串拼接吗？

不能。少量固定片段用直接拼接更易读；需要流式输出时使用 Writer；只有在多片段集中组装确实成为热点或内存复制成本明显时，Builder 才更合适。

总结来说，strings.Builder 的价值是把大文本组装变成“集中写入、最后交付”：先用零值开始，再用 Write 系列表达结构，能估算时用字节数调用 Grow，并用局部实例、Reset 和 benchmark 边界控制复用风险。这样优化的是可解释的内存写入路径，而不是简单地把所有字符串代码替换成一个 API。