strings.Builder.Reset()只重置长度不释放内存，为避免重复分配；String()后WriteString()会强制复制缓冲区；复用需单goroutine，sync.Pool中取出必须Reset()。
strings.Builder.Reset() 不清内存，只重置长度
Reset() 的作用非常明确：它把 b.len 设为 0，但保留整个底层数组 b.buf 的容量和已有内存。这不是 bug，是刻意设计——避免重复分配、降低 GC 压力。
常见错误现象：b.String() 返回空字符串，且无 panic；调试时反复检查逻辑，却忽略 builder 其实还在“接着上次写”。
- 从
sync.Pool取出的实例，必须调b.Reset()，不能假设“刚拿出来的就是干净的” - 循环中写
var b strings.Builder→ 每次新建结构体，底层数组无法复用，GC 压力悄悄上升 - 误以为
Reset()会释放内存 → 实际上 10MB 曾写入过的 builder，Reset 后仍占着那块内存
WriteString() 和 String() 的调用顺序影响性能
String() 看似只是取结果，但它会将底层数组标记为“已暴露”。一旦标记，后续任何 WriteString() 都会强制复制整个缓冲区——这是为了防止返回的字符串被意外修改（Go 字符串不可变语义要求）。
这意味着：在 hot path 中，如果先 b.String() 再 b.WriteString()，builder 就退化成 += 级别的开销。
立即学习“go语言免费学习笔记（深入）”；
- 高频拼接场景（如 HTTP handler）应避免在中间调
String()，等全部写完再一次性取结果 - 若需中途取值并继续拼接，考虑拆成两个 builder，或改用
bytes.Buffer（但注意它每次String()都做 UTF-8 检查，开销略高） -
WriteString()和Write()别混用：混用会触发“非字符串安全”标记，同样导致String()强制拷贝
Reset() vs 重新声明变量：什么情况下该换新实例？
多数场景下 b.Reset() 更轻量，因为它不 new 内存，只归零长度。但有两个例外值得警惕：
- builder 曾写入巨量内容（比如日志聚合中拼过 5MB），之后长期闲置 → 底层数组持续占用，此时手动
b = strings.Builder{}反而更合理 - 循环中拼接内容长度差异极大（一轮拼 1KB，下轮只拼 10B）→ 复用大容量 buffer 造成内存浪费，不如新建
- 单次拼接少于 3 次、总长低于几百字节 → 直接用
+更简洁，编译器还能常量折叠，Reset()反而多此一举
复用 strings.Builder 必须满足单 goroutine 使用
strings.Builder 没有锁，所有方法都不是并发安全的。即使你用了 sync.Pool，也必须确保每个取出的实例只在一个 goroutine 内使用。
常见踩坑点：
- 从池里取 builder，传给多个 goroutine 并发写 → 数据错乱、
String()返回不可预期内容 - 在 handler 中复用全局 builder 变量 → 多个请求同时写，结果互相覆盖
- 误以为
Reset()能解决并发问题 → 它只管长度，不管竞争
真正需要跨 goroutine 拼接时，要么加锁，要么每个 goroutine 自己拿自己的 builder 实例——sync.Pool 正是为此而设，但前提是每次取出后立刻 Reset()，用完放回。
