Go strings.Builder 的 String 返回值能否长期保存：复用边界与写入规则

做日志拼接时，常见写法是把一个 strings.Builder 放进循环里反复追加，然后把 String() 的结果交给下游。真正容易出问题的不是拼接本身，而是有人继续修改 Builder 后，误以为之前保存的字符串也会跟着变化，或者直接复制 Builder 继续使用。

String() 返回的字符串可以保存；Builder 后续写入不会改变已经返回的字符串，但 Builder 不能被复制，复用时应明确调用 Reset()，并把它当作新的构建周期。

先复现：保存 String() 结果后再继续写

先做一个小实验，不看容量、不做基准，只观察两个字符串的内容。把构建过程拆开，才能看清 WriteString、String() 与后续写入之间的边界。

package main

import (
    "fmt"
    "strings"
)

func main() {
    var builder strings.Builder
    builder.WriteString("request=")
    builder.WriteString("42")

    first := builder.String()
    builder.WriteString(" status=ok")
    second := builder.String()

    fmt.Printf("first=%q\n", first)
    fmt.Printf("second=%q\n", second)
}

运行后，first 仍是 request=42，second 才包含 status=ok。这条调用链可以概括为 strings.Builder → WriteString → String() → 结果文本：结果一旦交给下游，就不要把 Builder 当成结果对象继续操作。

为什么旧字符串不会随着 Builder 一起变长

从使用者角度看，String() 返回的是一个字符串值，而不是“每次读取都重新观察 Builder 的窗口”。保存 first 后再次调用 WriteString，只是让 Builder 的当前构建内容前进；它不会把已经保存的 first 变成另一个字符串。

因此，日志、缓存键或响应片段需要跨越当前构建周期时，可以先保存 String() 的结果。需要注意的是，这个结论不代表 Builder 可以随便并发使用，也不代表复制 Builder 是安全的；它只说明结果字符串与后续构建动作有清楚的值边界。

复用 Builder 时，Reset() 应该放在新一轮开始处

如果同一个函数要生成多条短文本，通常可以在一轮结束后调用 Reset()，下一轮再从空内容开始。不要把“清空当前内容”和“修改上一轮已经返回的字符串”混为一谈。

func makeLabel(id int) string {
    var builder strings.Builder
    builder.WriteString("item-")
    builder.WriteString(fmt.Sprint(id))
    return builder.String()
}

func makeTwoLabels() (string, string) {
    var builder strings.Builder

    builder.WriteString("item-1")
    first := builder.String()

    builder.Reset()
    builder.WriteString("item-2")
    second := builder.String()
    return first, second
}

Reset() 之后，Builder 回到空的构建状态；first 仍然是 item-1，second 是新的 item-2。这里的安全边界来自“每轮先完成 String()，再 Reset()，最后开始新的 WriteString”，而不是来自某个隐含的全局缓存。

复制 Builder 为什么是另一类错误

strings.Builder 的文档明确提醒：不要复制已经使用过的 Builder。最容易出现复制的场景，是把 Builder 当作普通结构体值传参，或者把包含 Builder 的结构体按值赋给另一个变量。

type lineWriter struct {
    builder strings.Builder
}

func appendSuffix(w lineWriter) lineWriter {
    w.builder.WriteString("-suffix")
    return w
}

这段代码的问题不在“能不能通过编译”，而在复制动作可能带走 Builder 的内部状态。实际代码里应让拥有 Builder 的对象保持单一所有者，或传递指针并避免在构建过程中产生值拷贝。若只是需要结果，传递 string；若需要继续构建，传递明确的 *strings.Builder，并把生命周期限制在一个同步调用链内。

几个边界问题，别用性能猜测代替验证

String() 之后还能不能继续 WriteString

可以继续构建并再次调用 String()，如实验中的 first 和 second。但应把每个返回值视为独立结果，不要用 Builder 的后续操作去“更新”旧字符串。

Reset() 之后旧结果会不会被清空

不会。Reset() 清空的是 Builder 的当前内容；已经保存的字符串仍应按自己的值使用。新一轮必须重新执行 WriteString，不能假设 Reset 会保留上一轮的前缀。

多个 goroutine 能不能共用一个 Builder

不要这样做。Builder 的写入、String() 和 Reset() 应放在一个有明确同步边界的调用链里。需要并发生成文本时，每个任务使用自己的 Builder，最后再汇总结果。

相关问题：什么时候不用 strings.Builder

只有两个字符串相加也要用 Builder 吗

通常没必要。简单拼接优先选择可读的字符串表达式；Builder 更适合片段数量多、拼接路径清楚且确实需要顺序写入的场景。

为什么不直接把 Builder 放进 sync.Pool

可以在严格管理生命周期时讨论复用，但取出后必须由单个任务独占，使用完调用 Reset()，不能把 Builder 或其内部状态跨任务传播。先保证正确性，再用测量结果决定是否需要池化。

保存 String() 结果后还能复用底层内存吗

不要把实现细节当成接口承诺。代码只依赖字符串结果的值语义；是否复用容量、何时分配由标准库实现决定，不能据此设计可变字符串行为。

收尾检查

看到 strings.Builder 时，可以按三句话检查：先用 WriteString 完成当前内容，再用 String() 交付一个结果，下一轮从 Reset() 开始；Builder 本身不复制、不跨 goroutine 共享。这样既能保留顺序构建的便利，也不会把 Builder 的生命周期误当成字符串结果的生命周期。