字符串拼接慢是因为每次+都分配新内存；go中字符串不可变，每次+需创建新底层数组并全量拷贝旧内容，10次拼接可能触发10次内存分配与复制，循环中性能急剧下降。
字符串拼接慢，是因为每次 + 都分配新内存
Go 中用 + 拼接字符串时，底层会为每次结果创建新底层数组——字符串不可变，旧内容得全拷贝一遍。10 次拼接可能触发 10 次内存分配和复制，尤其在循环里，性能断崖式下跌。
常见错误现象：for i := 0; i 跑得越来越慢，<code>pprof 显示大量 runtime.makeslice 和内存分配。
- 小量固定拼接（如
"prefix" + name + ".txt"）：直接用+，编译器能优化成一次分配 - 动态长度、循环内拼接（如日志组装、SQL 构建）：必须换方案
- 已知最终长度？优先用
strings.Builder，它预分配底层数组，追加不 realloc
strings.Builder 比 bytes.Buffer 更轻、更专一
strings.Builder 是 Go 1.10+ 专为字符串拼接设计的类型，零拷贝转字符串；bytes.Buffer 是通用字节缓冲，转 string 时需拷贝底层字节（即使内容全是 ASCII）。
性能差异明显：10 万次拼接，strings.Builder 通常快 20%~30%，内存分配少一半。
立即学习“go语言免费学习笔记（深入）”；
- 必须调用
builder.Grow(n)预估容量（比如知道总长 ≈ 512 字节），避免多次扩容 - 不能复用
strings.Builder实例后不清空——它没Reset()方法，得用builder.Reset()（有！Go 1.11+ 支持）或重新声明 -
bytes.Buffer仍有必要：当你需要写入二进制、或后续要调WriteTo(io.Writer)等字节流操作时
var b strings.Builder
b.Grow(1024)
for _, s := range parts {
b.WriteString(s)
}
result := b.String() // 零拷贝
别在 fmt.Sprintf 里拼接大量字符串
fmt.Sprintf 内部用 strings.Builder，但多了格式解析开销。如果只是连字符、无格式化（如 s1 + s2 + s3），它比直接 strings.Builder 慢 3–5 倍。
错误使用场景：循环中写 log.Printf("id=%d, name=%s, time=%v", id, name, t) —— 这是合理用法；但若写成 msg := fmt.Sprintf("%s%s%s", a, b, c) 就纯属浪费。
- 纯拼接 → 用
strings.Builder或+（小量） - 含格式化（数字转字符串、对齐、动词控制）→
fmt.Sprintf合理 - 高频日志？考虑结构化日志库（如
zap），它们内部已做 Builder 复用和池化
并发写同一个 strings.Builder 会崩溃
strings.Builder 不是线程安全的。没有锁，也没有原子字段——并发调用 WriteString 或 String() 可能导致数据错乱、panic 或静默截断。
典型踩坑：goroutine 池里共用一个 builder 实例，或者误以为 “只读 String() 没问题”，其实 String() 内部依赖当前 buf 状态，而写操作可能正在改它。
- 每个 goroutine 自己 new 一个
strings.Builder，用完丢弃（开销极小） - 真要复用？用
sync.Pool管理 builder 实例，但注意：取出来必须先Reset() - 别试图加锁包装 builder——那不如直接用
bytes.Buffer，它至少文档明确说 “not safe for concurrent use”，而 builder 连这句提示都没给
