Go strings.Builder 的 String 返回值能否长期持有：继续写入时的引用与复用边界

线上日志拼接通常会把同一个 strings.Builder 用很多次：先写前缀，取出一次 String()，再继续追加下一段。这个用法并不会让已经拿到的字符串跟着变化；真正需要小心的是，Builder 本身不能复制，且复用时要把“字符串结果”和“构建器状态”分开看。

String() 返回的字符串可以长期保存，后续 WriteString 或 Reset 不应改写它；但不要复制非零 Builder，也不要把一个正在写入的 Builder 交给多个 goroutine。

先把 String、Len 和 Cap 放回同一条数据路径

Builder 内部维护一个字节缓冲区 b.buf。Len() 返回已经写入的字节数，Cap() 返回底层切片容量，而 String() 只把当前有效长度转换成字符串。三者观察的是同一个构建过程，却不是同一个概念。

var b strings.Builder
b.WriteString("go")
fmt.Println(b.Len(), b.Cap(), b.String())

b.WriteString(" tutorial")
fmt.Println(b.Len(), b.Cap(), b.String())

这里第二次写入后，Len() 一定增加；Cap() 可能保持不变，也可能在空间不足时增长。容量变化不代表旧的字符串结果被修改，因为旧结果的长度和内容已经确定。

继续 WriteString 时，先前的字符串为什么不跟着追加

实际排查时最容易误判的是下面这段代码：开发者看到 String() 实现追求少拷贝，就担心 s1 会随着 Builder 继续写入。Go 官方测试连续写入 alpha、beta、gamma，并逐一检查之前的结果仍是原来的内容。

var b strings.Builder
b.WriteString("alpha")
s1 := b.String()

b.WriteString("beta")
s2 := b.String()

fmt.Println(s1) // alpha
fmt.Println(s2) // alphabeta

工程上的判断方式很简单：如果函数需要记录每一阶段的结果，可以保存 s1、s2；如果只是最终输出，就不要在循环里反复保存中间字符串。两者的内存生命周期不同，别用“少一次复制”的猜测替代测试。

一个容易漏掉的边界：不要复制非零 Builder

官方类型注释明确写着“Do not copy a non-zero Builder”。也就是说，下面这种值传递不是安全的复用方式：

func appendSuffix(b strings.Builder) string {
    b.WriteString("-done")
    return b.String()
}

应该传指针：

func appendSuffix(b *strings.Builder) string {
    b.WriteString("-done")
    return b.String()
}

这不是为了让字符串结果“更稳定”，而是避免复制 Builder 内部用于检测复制的状态和缓冲区关系。若需要把一个结果交给另一个流程，交付 string，不要交付正在使用的 Builder。

Reset 之后复用，旧结果仍然属于旧结果

Reset() 将 Builder 恢复为空状态；当前实现会把 b.buf 置为 nil。因此一个常见的批处理循环可以这样写：

var b strings.Builder
var lines []string

for _, name := range []string{"api", "worker"} {
    b.Reset()
    b.WriteString("module=")
    b.WriteString(name)
    lines = append(lines, b.String())
}

fmt.Println(lines[0]) // module=api
fmt.Println(lines[1]) // module=worker

这段代码的状态变化是：Reset 清空当前 Builder，WriteString 写入新内容，String 产出一条独立结果，再进入下一轮。不要把 b.String() 的结果理解为“指向一个会不断刷新的变量”。

什么时候应该放弃复用

如果一次任务写入了很大的内容，随后只需要生成很短的字符串，继续复用同一个 Builder 可能让容量和任务峰值绑定在一起。此时可以让 Builder 离开作用域，或重新声明一个零值 Builder；Cap() 只能帮助观察容量，不能替代内存画像。

把一次安全复用整理成可执行的检查清单

相关问题：字符串结果和构建器状态怎么分工

String() 会不会每次都复制全部内容？

实现目标是尽量减少复制，但调用方只应依赖它返回当前内容这一语义，不应依赖内部是否复制来设计并发或生命周期。

Reset 后还能继续 WriteString 吗？

可以。Reset 后 Builder 回到空状态，后续写入会重新建立当前结果；官方测试也覆盖了 Reset 后写入不影响先前字符串。

Builder 能不能放进结构体后按值返回？

非零 Builder 不应复制。结构体若包含它，应避免值复制；更稳妥的接口是返回最终字符串，或明确使用指针。

最后一次验证：用官方测试关注语义，不猜实现细节

这类问题最可靠的验证顺序是先读 go.dev/src/strings/builder.go 的类型注释、String、Reset，再看 builder_test.go 中对连续写入和 Reset 的断言。文章中的结论只覆盖公开语义：字符串结果保持不变、Builder 不应复制、容量与长度分开观察。至于编译器和运行时在某个版本的具体分配策略，不要把一次基准测试当成永久承诺。