strings.builder 底层操作字节而非符文，不校验 utf-8 合法性，writerune 是伪实现，误用会导致乱码；需配合 grow 预分配、reset 复用、避免混用 write/writestring 才能发挥性能优势。
strings.Builder 不是“字符切片拼接器”，它底层用的是 []byte，不是 []rune；它不处理 Unicode 语义，也不做字符边界校验——拼进去什么字节，最后就得到什么字符串。想靠它做“字符级安全拼接”会出乱码，这是根本性误解。
为什么不能把 strings.Builder 当成 rune 切片用
Go 的 strings.Builder 完全按字节操作：写入 "café"（4 字节）或 "??"（多个 UTF-8 字节）都没问题，但它不会验证是否合法 UTF-8，也不会对 rune 做拆分或对齐。一旦你误用 WriteRune（它其实只是把 rune 强转成 byte 写入），就会破坏编码——比如写入 0x1F468（? 的一部分）直接当单字节塞进去，结果就是非法字节序列。
-
WriteRune在strings.Builder中是**伪实现**，不应使用 - 需要真正按字符拼接？先用
utf8.DecodeRuneInString拆，再用string(r)转成合法字符串，然后WriteString - 已有
[]rune切片？别直接拷贝进 Builder；先string()转成字符串再写，否则可能丢数据
strings.Builder 必须 Grow 才快，否则和 + 差不多
默认零值的 strings.Builder{} 底层容量为 0，第一次 WriteString 就触发扩容——初始分配 64 字节，之后按 2 倍增长。100 次追加平均长度 20 字节，没 Grow 就会扩容 5–7 次，每次都要复制已有内容；而提前 b.Grow(2048) 可避免所有中间拷贝。
- 知道总长 → 直接
b.Grow(total)，最稳 - 只知道上限 →
b.Grow(1.5 * estimated)，留点余量 - 完全未知 → 接受前几次扩容，但别在高频循环里反复新建
var b strings.Builder -
Grow不影响当前Len()，只预分配底层数组空间
复用 Builder 必须 Reset，且不能混用 Write 和 WriteString
Reset() 只设 b.len = 0，底层数组仍保留；但若之前调过 Write([]byte{...})，内部标记会被设为 “非字符串安全”，后续 String() 就会强制拷贝一次底层数组——性能掉一档，还掩盖了类型混用问题。
- 纯拼字符串变量 → 全程只用
WriteString - 已有
[]byte数据（如从网络读取）→ 只用Write，别转string再写 - 复用前必须
b.Reset()，哪怕是从sync.Pool取出来的 -
String()后不能再写，否则下次Write会重新分配内存
真正难的不是怎么写，而是判断该不该用：拼 2 个固定字符串？用 +；已有 []string？用 strings.Join；只有边查边拼、长度不可知、次数 ≥3，才轮到 strings.Builder——而且得配 Grow、守规则、单 goroutine 用。漏掉任意一点，性能优势就没了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
