strings.builder 必须初始化或复用前调用 reset()，否则内容可能为空或错乱；应统一使用 writestring() 拼接 utf-8 文本，避免混用 write()；循环中优先 reset() 复用而非重新声明；已知切片应优先用 strings.join()。
strings.Builder 不是“写了就能用”，不初始化或复用前不 Reset()，拼出来的东西可能为空、错乱，甚至静默失败。
strings.Builder 必须初始化才能写入
声明 var b strings.Builder 后，它处于零值状态。Go 1.10+ 允许对零值实例直接调用 WriteString()，但仅限「从未写入过」的首次使用；一旦写入过，再复用就必须显式调用 Reset()。否则行为不可靠——某些版本下会静默丢弃内容，String() 返回空字符串，且无 panic 或错误提示。
- 从
sync.Pool取出的strings.Builder实例，每次取出后必须b.Reset()，不能依赖零值 - 错误写法：
fmt.Println(b)→ 输出类似{[] 0 0}，不是拼接结果；必须用fmt.Println(b.String()) -
String()返回的是新字符串拷贝，不影响 builder 内部状态；但之后若未Reset()就继续WriteString()，内容会追加到旧数据后面
循环拼接必须用 WriteString()，别混用 Write()
WriteString() 接收 string，Write() 接收 []byte。混用会导致 String() 在内部触发一次额外拷贝（因为底层缓冲区可能被标记为“非字符串安全”），性能下降且语义混乱。
- 只拼 UTF-8 文本时，统一用
WriteString(s)；避免Write([]byte(s)) - 如果传入的是已有的
[]byte（比如从网络读取的原始字节），且确认是合法 UTF-8，可先转string再WriteString()，比直接Write()更安全 -
WriteByte()和WriteRune()可以穿插使用，但注意WriteRune()对代理对（surrogate pair）处理正确，适合动态插入 Unicode 字符
复用 Builder 要 Reset()，不是重新声明变量
在循环中反复写 var b strings.Builder 看似简洁，实则每次都会初始化新结构体，虽轻量但无法复用已分配的底层数组，GC 压力略高；而 b.Reset() 只重置长度为 0，保留原有容量，下次 WriteString() 可直接追加。
-
Reset()不释放内存，也不清空底层数组 —— 这是设计使然，目的是避免重复分配 - 预估总长可用
Grow(n)，比如日志行平均 256 字节，循环前调b.Grow(4096)；但别过度预估（如Grow(1e6)），浪费内存 - 多 goroutine 并发写同一个
strings.Builder是未定义行为；必须加锁，或每个 goroutine 独立实例
Builder 不是万能替代品：该用 Join 的时候别硬套
如果你手头已经是一个 []string 切片，比如从 HTTP Header 解析出的键值对列表，直接用 strings.Join(parts, ", ") 比循环调 WriteString() 更快、更干净——它单次分配、一次拷贝，底层无扩容逻辑。
-
strings.Join([]string{"a", "b", "c"}, "")等价于"abc"，分隔符为空时就是纯拼接 - 不要为了用
Join先把字符串strings.Split(s, ",")再拼回去——白费一次切片分配和遍历 - 非字符串切片（如
[]int）需手动转成[]string，用strconv.Itoa比fmt.Sprint更轻量（后者有反射开销）
真正容易被忽略的点是：Builder 的“高效”只在它被正确复用时才成立；一次性的、没调 Reset() 的、混用 Write() 的、或者本该用 Join 却绕路用 Builder 的场景，不仅没收益，还增加维护成本。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
