Go strings.Builder 如何避免拼接时意外复制

在循环里用 result += part 拼接字符串，旧结果通常要参与下一次构造；片段多、结果长时，中间字符串复制就会成为额外成本。strings.Builder 的正确用法是让一个 Builder 持有可增长的字节缓冲区，连续写入后只在需要结果时调用 String()。它能减少重复拼接的复制，但不能承诺整个过程完全没有分配：缓冲区扩容、调用方保存结果等仍可能产生成本。

strings.Builder 真正避免的是哪一次复制

字符串在 Go 中是不可变值。连续使用 += 时，每次得到的新字符串都要容纳旧内容和新片段；旧内容被反复带入后续结果。Builder 则把正在构造的内容放进自己的缓冲区，WriteString 直接追加，WriteByte 写入单个字节，WriteRune 写入一个 Unicode 码点的 UTF-8 编码。

String() 返回累计字符串，Len() 统计已写入的字节数，Cap() 反映底层缓冲区容量。不要把“减少中间复制”理解成“所有操作零分配”，尤其是缓冲区不够时，Builder 仍要换一块更大的空间并复制已有内容。

用 Grow 减少扩容，但先按字节估算

如果接口返回格式、日志模板或序列化文本的长度大致可知，可以在第一次写入前调用 Grow。它保证至少有 n 个额外字节可写入而不再分配；n 为负数会 panic。中文字符通常占多个 UTF-8 字节，所以不要把“字符数量”直接当成容量。

package main

import (
	"fmt"
	"strings"
)

func buildReport(name string, count int) string {
	var b strings.Builder
	// 这里按 ASCII 模板和名称的字节长度预留，避免明显的中途扩容。
	b.Grow(len("name=;count=") + len(name) + 20)
	// WriteString 只追加文本；Builder 仍由当前函数独占。
	b.WriteString("name=")
	b.WriteString(name)
	b.WriteString(";count=")
	fmt.Fprint(&b, count)
	// String 读取最终结果；后续不要继续修改并发共享的 Builder。
	return b.String()
}

func main() {
	// 这个调用只演示结果形态，不代表固定的性能数据。
	fmt.Println(buildReport("cache", 12))
}

这里的预留量只是工程估算，不是硬编码的性能保证。若输入来自用户或外部文件，无法可靠预测总长度时，直接写入也可以；为了省下一次扩容而预留过大的容量，反而会让短结果占用更多内存。

非零 Builder 不要复制，String 后也要守住边界

官方实现会记录 Builder 的接收者地址。一个 Builder 写入过内容后，如果发生结构体按值复制，再通过复制品写入，就可能触发 strings: illegal use of non-zero Builder copied by value。因此，包含 Builder 的函数应尽量保持单一所有者；需要抽取写入逻辑时传 *strings.Builder，不要传值。

func appendHeader(b *strings.Builder, title string) {
	// 指针参数让调用方继续持有同一个 Builder，避免复制非零值。
	b.WriteString("# ")
	b.WriteString(title)
	b.WriteByte('\n')
}

func makeDocument(title string) string {
	var b strings.Builder
	// 单一函数负责创建和最终读取，所有权边界清晰。
	appendHeader(&b, title)
	return b.String()
}

String() 后不要再把同一个 Builder 当作可并发共享对象。短时间内的顺序追加通常没问题，但 Builder 本身不是并发安全容器；跨请求复用时更容易把上一次内容、容量和当前写入者混在一起。若确实需要复用，可以在确认旧字符串已不再依赖后调用 Reset()，并让下一轮仍只有一个写入者。

用 Cap、Len 和基准测试判断优化是否成立

排查“Builder 还是很慢”时，先记录输出长度和容量，而不是只看 API 名称。Len() 应与最终字符串的字节长度一致；Cap() 大于 Len 只说明还有可用空间，不说明一定比 + 快。

实际项目可以为两个版本写同一组 benchmark，在相同输入、相同输出和相同编译参数下比较。只有长文本、循环次数高或分配出现在热点路径时，Builder 的收益才通常值得维护复杂度；普通的几段字符串连接，保持可读性更重要。

常见问题

Grow 的参数应该填字符数还是字节数？

填预计追加的字节数。对中文、表情或其他多字节 UTF-8 内容，字符数和字节数可能不同，不能直接画等号。

strings.Builder 可以放进结构体并返回吗？

可以，但要避免返回或传递过程中复制已经写入的 Builder。更稳妥的做法是让结构体保持单一所有者，或让方法使用指针接收者。

Reset 后容量一定会保留吗？

不要把容量保留当成跨版本或跨实现的业务契约。Reset 的语义是清空 Builder；如果容量复用对性能重要，应通过基准测试确认，而不是凭猜测依赖内部细节。

判断 strings.Builder 是否合适，核心不是把所有 + 都替换掉，而是确认拼接热点、估算字节容量、保持 Builder 不被复制，再用基准数据决定是否保留这层优化。