当前位置：首页 > 文章列表 > Golang > Go教程 > Go strings.Builder 的 String 返回值能否长期持有：继续写入时的引用与复用边界

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

来源：17golang原创 2026-08-28 08:25:42 0浏览收藏

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

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

要点速览

String() 得到的是当前长度范围内的字符串视图，后续写入会走独立的增长或新区域，官方测试也验证了历史结果不变。
Reset() 会把 b.buf 置空，之后重新写入不会改变之前保存的字符串。
Cap() 是底层缓冲区容量，不是本次结果长度；复用 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() 可能保持不变，也可能在空间不足时增长。容量变化不代表旧的字符串结果被修改，因为旧结果的长度和内容已经确定。

Go strings.Builder 中 String、WriteString 与 s1 的数据流关系

继续 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() 的结果理解为“指向一个会不断刷新的变量”。

Go strings.Builder 执行 Reset 后由 b.buf 重新构建而不改变 s1 的状态变化

什么时候应该放弃复用

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

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

检查项	正确判断	常见误区
保存 String 结果	后续写入、Reset 后仍按原内容使用	认为结果会实时反映 Builder
传递 Builder	使用 `*strings.Builder`	按值传递非零 Builder
并发复用	外部加同步，或每个 goroutine 独占实例	把 Builder 当成并发安全缓冲区
观察容量	用 `Cap()` 做诊断	用容量推断字符串长度或内存总量

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

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