strings.Builder 写入前必须初始化，否则行为不可靠；正确做法是声明后调用 Reset() 或依赖 Go 1.10+ 零值（仅限未写入前），复用时必重置，String() 返回拷贝，不共享底层数组。
strings.Builder 写入前必须初始化
不初始化就直接 WriteString 或 Write，程序不会 panic，但行为不可靠——内部指针可能为 nil，某些 Go 版本下会静默失败或触发 runtime 错误。这不是 bug，是设计使然：strings.Builder 不是零值安全的类型。
- 正确做法：声明后立刻调用
Reset()或直接用var b strings.Builder（Go 1.10+ 零值可用，但仅限于未写入前；一旦写入过，再复用必须Reset()） - 常见错误现象：
Builder.String()返回空字符串，且无报错，调试时容易误判为逻辑问题 - 如果从池里取
strings.Builder（比如sync.Pool），每次取出后必须b.Reset()，不能依赖零值
Builder.WriteString 比 += 更快，但不是万能加速器
拼接少量短字符串时，+= 和 Builder.WriteString 性能差距微乎其微；真正受益场景是循环内多次追加、或拼接总长超过几百字节的文本。
- 底层原理：Builder 复用底层
[]byte，避免频繁分配；而s += t每次都新建字符串，触发 GC 压力 - 性能影响：1000 次追加长度为 10 的字符串，Builder 耗时约是
+=的 1/5，内存分配次数从 1000 次降到 2–3 次 - 注意点：Builder 的
Grow(n)只是建议容量，不保证立即分配；过度预估（比如Grow(1e6)）反而浪费内存
Builder.String() 返回的是拷贝，不是底层数据引用
调用 String() 后得到的字符串与 Builder 内部缓冲区完全无关，后续对 Builder 的修改不会影响已返回的字符串——这点和 bytes.Buffer 一致，但常被误以为“共享底层数组”。
- 为什么这样设计：防止字符串被意外修改（Go 字符串是只读的），也避免因 Builder 复用导致字符串内容突变
- 容易踩的坑：有人试图用
unsafe.String绕过拷贝以提升性能，这是危险操作，在 Go 1.20+ 中会被 vet 工具警告，且在 GC 移动内存时可能引发崩溃 - 兼容性提示：该行为自 Go 1.10 稳定至今，无变更风险，可放心依赖
Builder 不能替代 bytes.Buffer 的所有用途
如果你需要读取中间结果、支持 Seek、写入二进制数据、或对接 io.Reader/io.Writer 接口，strings.Builder 就不合适——它只面向 UTF-8 文本拼接，且只提供写入和最终转字符串的能力。
立即学习“go语言免费学习笔记（深入）”；
- 典型误用：想用 Builder 实现“边写边读”，结果发现没有
Bytes()或Next()方法 - 参数差异：
strings.Builder没有构造函数参数，无法指定初始容量；bytes.Buffer可用bytes.NewBuffer(make([]byte, 0, 1024))预分配 - 真实场景判断：日志行拼接、SQL 拼装、HTML 片段生成 → 用 Builder；协议编码、流式解析、需要反复读写 → 用
bytes.Buffer
Builder 的边界很清晰：只做一件事，做好一件事。越想让它干更多活，越容易掉进“为什么没这个方法”的困惑里。它的初始化、复用、拷贝语义这三点，才是日常出问题最多的地方。
