循环拼接字符串必须用strings.Builder并显式调Grow()，禁用+=；因字符串不可变，+=导致O(n²)拷贝和GC飙升；已知切片优先用strings.Join；bytes.Buffer仅适用于需Bytes()或兼容旧版等特定场景。
循环里用 += 拼字符串，性能会断崖式下跌——不是“慢一点”，是 GC 飙升、延迟毛刺、pprof 里满屏 runtime.mallocgc。真正该用的是 strings.Builder，但必须配 Grow()，否则快不起来。
为什么循环中 += 是性能黑洞
Go 字符串不可变，每次 s += "x" 都要：分配新底层数组 → 全量拷贝旧内容 → 追加新字节 → 丢弃旧字符串。拼 1000 次，实际拷贝字节数接近 O(n²) 级别。
- 典型错误现场：
for _, line := range lines { log += line + "\n" } - 现象：压测时 GC 频繁触发，
go tool pprof显示大量runtime.makeslice和小对象分配 - 仅适用场景：≤3 个字面量拼接（如
"GET " + path + " HTTP/1.1"），编译器能静态合并成单次分配
怎么让 strings.Builder 真正快起来
strings.Builder 快，是因为底层复用 []byte，WriteString() 是均摊 O(1)；但它默认初始容量为 0，不预估就等于白用。
- 必须调
b.Grow(estimatedTotalLen)：知道总长？直接传（如拼 100 个 ID，每个约 24 字节，就b.Grow(2400)）；不知道？按场景经验预估（日志行 ≤512B，HTML 片段 ≤4KB），宁大勿小 - 只用
b.WriteString(s)或b.WriteRune(r)：混用b.Write([]byte(s))或fmt.Fprintf(&b, ...)会多一层解析，慢 3–5 倍 -
b.String()只调一次，且必须放在最后：反复调会触发无意义的底层 copy；调完就不能再写，Builder 也不再可安全复用（Reset()不清空底层数组）
strings.Join 什么时候比手写 Builder 更好
strings.Join 内部就是用 strings.Builder 实现的，还带最优预分配逻辑，适合「所有片段已就绪 + 同一分隔符」场景。
立即学习“go语言免费学习笔记（深入）”；
- 适用：
strings.Join([]string{"a", "b", "c"}, ",")，性能比手写 Builder 循环快 10%～20% - 不适用：边查 DB 边拼 CSV 行——先
append到[]string再 Join，slice 自身扩容开销可能反超直接 Builder 流式写入 - 注意：
strings.Join(nil, ",")会 panic；空切片可以，但不能传nil
什么情况下才考虑 bytes.Buffer
bytes.Buffer 不是为纯字符串拼接设计的，它接口更重、String() 每次都做 copy、还带锁（虽不常触发），性能略低于 strings.Builder。
- 真实使用理由只有三个：
– 需要后续调buffer.Bytes()写文件或网络（避免再转string）
– 已混用fmt.Fprintf(&b, ...)或需ReadFrom等字节流操作
– 必须兼容 Go 1.9 或更早版本（2026 年基本不用考虑） - 并发写同一个
strings.Builder会崩溃——它没锁也没原子字段；而bytes.Buffer虽线程安全，但代价是性能损耗
真正难的不是选 API，而是判断“拼接”是否必要：比如日志场景，与其拼好再写，不如用 io.WriteString(w, s) 流式输出；比如数字拼接，strconv.AppendInt 直接写 Builder 底层切片，比 fmt.Sprintf 或 strconv.Itoa 都省。
