strings.builder 必须初始化或复用前调 reset()，否则 string() 可能返回空字符串且 len() 非零；混用 writestring() 和 write() 会触发强制拷贝；循环中应复用而非重建；预估长度可用 grow()；并发需加锁；固定短串用 + 更优。
直接用 strings.Builder 拼接字符串，不初始化或复用前不 Reset()，大概率拼出空字符串，且无任何报错提示——这是静默失败，不是 bug。
strings.Builder 必须初始化或复用前调 Reset()，否则 String() 返回空
声明 var b strings.Builder 后它是零值，Go 1.10+ 允许首次 WriteString() 直接用，但一旦写入过，再复用就必须 b.Reset()。否则行为未定义：某些版本下 b.String() 返回空字符串，b.Len() 却可能非零，调试时极易误判为逻辑错误。
- 从
sync.Pool取出的实例，每次取出后必须b.Reset()，不能依赖“刚从池里拿出来的就是干净的” -
fmt.Println(b)输出类似{[] 0 0}，不是拼接结果；必须用fmt.Println(b.String()) -
Reset()不释放内存，只设b.len = 0，保留底层数组容量——这是设计使然，为避免重复分配
WriteString() 和 Write() 别混用，否则性能掉一截
WriteString() 接收 string，Write() 接收 []byte。表面都能拼，但混用会触发底层缓冲区的“非字符串安全”标记，导致后续 String() 调用时强制拷贝整个底层数组，白费 Builder 的优化意图。
- 拼接变量（如
name、path）或常量字符串 → 统一用b.WriteString(s) - 已有合法 UTF-8 的
[]byte（比如从io.Read()得到）→ 用b.Write(data)，避免转string多一次分配 - 插入单个字节（如分隔符）→ 用
b.WriteByte(' ')，比b.WriteString(" ")少一次字符串头访问 - 别用
WriteRune()拼 Unicode 字符——它不处理 UTF-8 编码，只是把rune强转成byte写入，会乱码
循环拼接必须复用 + Reset()，别每次 var b strings.Builder
在循环里反复写 var b strings.Builder，每次都会新建结构体，无法复用已分配的底层数组，GC 压力略高，且扩容次数更多。而 b.Reset() 只重置长度，保留容量，下次 WriteString() 可直接追加。
- 高频复用场景（如日志格式化函数）：声明一次，
Reset()后循环使用 - 预估总长可用
b.Grow(n)，比如日志行平均 256 字节，循环前调b.Grow(4096)；但别过度（如Grow(1e6)），浪费内存 -
Grow(n)是建议容量，不保证立即分配；完全不确定长度时，不调也行，默认按需翻倍扩容 - 多 goroutine 并发写同一个
strings.Builder是未定义行为；必须加锁，或每个 goroutine 独立实例
该用 strings.Join 的时候别硬套 Builder
如果你手头已经是 []string 切片（比如 HTTP Header 解析出的键值对），直接用 strings.Join(parts, ",")，它内部已做过 Grow() 优化，比手写循环 + WriteString() 还快。Builder 不是万能加速器，用错场景反而更慢。
- 拼接 ≥ 3 次、且长度不确定（如循环中累积日志、生成 HTML 片段）→ 适合
strings.Builder - 仅 2~3 个固定短字符串（如
"GET " + path + " HTTP/1.1"）→ 直接用+，编译器会做常量折叠，更简洁 - 需要读取中间结果、支持 Seek、写入二进制数据、或对接
io.Reader/io.Writer→ 该用bytes.Buffer，不是strings.Builder的用途
最易被忽略的点：复用 strings.Builder 时，Reset() 是必须动作，不是可选项；而 String() 调用后继续 WriteString()，会触发重新分配——这点和很多人直觉相反，但正是 Builder 设计的关键约束。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
