strings.Builder 是 Go 中安全拼接字符串的首选，但需满足拼接≥3次且内容长度不确定等条件；复用必须调 Reset()，避免数据残留；应统一使用 WriteString 或 Write，预估容量调 Grow()，且 String() 只调一次。
strings.Builder 是 Go 中安全拼接字符串的首选，但它本身不等于“安全”——用错方式反而引入数据残留、性能退化甚至静默错误。
什么时候该用 strings.Builder？不是所有拼接都适合
它只在明确满足以下条件时才值得引入：
- 拼接 ≥ 3 次，且每次内容长度不确定（如日志行、HTML 片段、SQL 参数动态生成）
- 已有
[]string切片？直接用strings.Join(parts, sep)，比手写Builder还快 10%～20% - 仅拼 2～3 个固定短字符串（如
"GET " + path + " HTTP/1.1"）？用+更简洁，编译器还能做常量折叠 - 需要格式化（如插入数字、布尔值）？优先用
strconv.Itoa或fmt.Sprint转换后传给WriteString，别在循环里调fmt.Sprintf
strings.Builder 复用必须调 Reset()，否则会叠加旧内容
这是最常被忽略的致命点：声明 var b strings.Builder 后首次可用，但一旦写入过，后续复用前不调 b.Reset()，行为未定义。某些 Go 版本下 b.String() 返回空字符串，且无 panic 提示。
- 从
sync.Pool取出实例后，必须先b.Reset()再写入，否则上一轮残留数据会拼在开头 - 在循环里写
var b strings.Builder→ 每次新建结构体，底层数组无法复用，GC 压力升高 -
Reset()不释放内存，只设b.len = 0；这是设计使然，为避免重复分配，但意味着内存占用不会自动回落
别混用 Write() 和 WriteString()，否则 String() 会强制拷贝
WriteString("x") 和 Write([]byte("x")) 表面等价，但混用会触发底层缓冲区“非字符串安全”标记，导致后续 b.String() 调用时强制拷贝整个底层数组——性能下降且语义混乱。
- 拼接纯
string变量（name、path等）→ 统一用b.WriteString(s) - 已有合法 UTF-8 的
[]byte（如从io.Read()得到）→ 用b.Write(data)，避免转string多一次分配 - 插入单个字节（如
' '）→ 用b.WriteByte(' ')，比WriteString(" ")少一次字符串头访问 - 别用
WriteRune()拼 Unicode：它只是把 rune 强转成 byte 写入，不处理 UTF-8 编码，必然乱码
Grow() 不是可选优化，是关键控制点
默认初始容量为 0，首次 WriteString() 才分配 64 字节；若不预估总长，中间可能多次扩容，性能优势大幅削弱。
立即学习“go语言免费学习笔记（深入）”；
- 已知拼接约 1000 个平均 4 字节的 ID →
b.Grow(4096)可避免中间扩容 - 拼日志行，每行 ≤ 512B →
b.Grow(512)足够；别过度（如Grow(1e6)），浪费内存 -
String()只调一次，且必须放在最后：反复调会触发无意义拷贝；调完再写入会强制重新分配内存（addr字段被设为nil） - 并发写同一个
strings.Builder实例会崩溃——它没锁，也没原子字段，这点和bytes.Buffer不同
encoding/json 或 text/template；而 strings.Builder 只负责把确定要拼的字节，以最低开销追加进去。 
