Go 问答：strings.Builder.String 返回后继续写会改掉旧字符串吗：共享存储与复制时机

把一段日志拼成字符串时，先调用 strings.Builder.String() 再继续写入，旧变量不会像可变字节数组那样被业务代码“顺手改掉”。真正需要留意的是 Builder 可能复用当前 buf，也可能在后续写入或 Grow 时换一块更大的缓冲区，所以不要把底层地址和容量当成可依赖的契约。

把 String() 的结果当作不可变字符串保存即可；如果还要继续构造下一段内容，使用同一个 Builder 没问题，但不要复制非零 Builder，也不要用 unsafe 去修改字符串底层数据。

先看一个容易误判的最小场景

下面的代码把第一次结果保存到 before，然后继续给 Builder 追加文本：

package main

import (
    "fmt"
    "strings"
)

func main() {
    var builder strings.Builder
    builder.WriteString("order=1001")
    before := builder.String()

    builder.WriteString(" status=paid")
    after := builder.String()

    fmt.Printf("before=%q\nafter=%q\n", before, after)
}

可核对的结果是 before 仍是 order=1001，after 才包含追加的状态。这里的结论来自字符串值的不可变语义，不应改写成“每次 String 都一定复制全部字节”，因为官方实现明确以减少复制为目标。

为什么继续写入不会按字节改写旧结果

strings.Builder 内部维护一个字节缓冲区 buf。官方源码中的 String() 根据当前缓冲区长度返回字符串；后续写入仍然由 Builder 管理，调用方拿到的是字符串值，不应该再通过不安全指针去修改它。

工程上更重要的是区分两种动作：String() 只观察当前内容，WriteString、Write 和 Grow 才会推动 Builder 的构造过程。若后续操作需要更多容量，Builder 可以申请新缓冲区，把已有字节搬过去；此时旧字符串继续代表它已经保存的内容，新字符串代表新的累计结果。

别把容量优化写成结果保证

调用 Grow(n) 的意义是为后续写入预留至少 n 个字节的容量，不是承诺 String 返回值会与某个切片共享地址。容量、分配次数和地址属于实现层面的观察项，只有在基准测试里才适合拿来比较。

用一次扩容实验确认边界

如果文章日志或缓存拼接有明确的估算长度，可以先 Grow，再写入内容：

var builder strings.Builder
builder.Grow(len("user=alice") + len(" role=admin"))
builder.WriteString("user=alice")
first := builder.String()

builder.WriteString(" role=admin")
second := builder.String()

这段代码的核对点不是打印出某个固定容量，而是 first 和 second 的值分别对应两个时刻。若追加内容超出预留空间，Builder 扩容仍不应改变 first 作为字符串结果的含义。

在日志拼接和循环里怎么写更稳

一个 Builder 只在一个构造流程里使用，不要把它按值传递给函数，也不要把非零 Builder 放进会复制它的结构体。官方文档特别提醒了这一点，标准库内部还会通过检查避免非零 Builder 被复制后继续写入。

func buildLine(user, role string) string {
    var builder strings.Builder
    builder.Grow(len(user) + len(role) + 6)
    builder.WriteString("user=")
    builder.WriteString(user)
    builder.WriteString(" role=")
    builder.WriteString(role)
    return builder.String()
}

如果一个长生命周期对象要重复构造多行文本，可以在一轮完成后保存结果，再调用 Reset() 开始下一轮。不要保存上一次的 Builder 副本；保存结果应该保存 string。

常见问题：三个边界如何判断

String 返回后继续写，旧字符串会变吗？

正常使用标准库 API 时，把旧结果作为字符串读取不会被后续 Builder 写入改成新内容。需要避免的是使用 unsafe 修改字符串存储，或把实现细节误当成接口保证。

什么时候应该用 strings.Builder 而不是 bytes.Buffer？

最终产物就是字符串、且主要操作是写入文本时，Builder 更直接；如果流程需要读取、截断或处理字节流，bytes.Buffer 的字节接口更合适。不要为了“零复制”在两者之间强行转换。

Reset 后还能继续复用吗？

可以。Reset() 把 Builder 置为空，之后可以重新写入；但复用只适用于同一个 Builder 实例，仍然不要复制非零 Builder。

最后的核对方式

测试这类问题时，至少同时断言第一次结果、第二次结果和 Reset() 后的第三次结果。容量变化可以辅助观察，但不要拿地址、容量或某个 Go 版本的内部实现替代字符串值断言。这样即使未来标准库优化了缓冲区策略，代码仍然只依赖公开行为。