循环拼接字符串必须用strings.Builder并显式Grow()，否则性能差200倍以上；因字符串不可变，+=每次分配新数组并复制旧内容，导致GC飙升和延迟毛刺。
循环内拼接字符串必须用
并显式调用
，否则性能可能差 200 倍以上；
在高频路径上不是“慢一点”，而是直接触发 GC 飙升和非线性延迟毛刺。
为什么
在循环里是性能断崖
Go 字符串不可变，每次
都要分配新底层数组、复制全部旧内容。1000 次拼接 ≈ 1000 次内存分配 + 至少几十 MB 无效拷贝，pprof 里满屏
就是它在作祟。
典型错误现场：
小量固定拼接（如
）没问题——编译器能静态合并；但只要进循环、或拼接次数不确定，
就该立刻替换。
立即学习
“
go语言免费学习笔记（深入）
”；
怎么正确用
它快，是因为底层复用
，
是均摊 O(1)；但它默认初始容量为 0，不预估就等于白用。
必须调
：知道总长？直接传值（如
）；不知道？按场景经验预估（日志行 ≤512B，HTML 片段 ≤4KB），宁大勿小
只用
或
：
会报错，
多一层格式解析，慢 3–5 倍
只调一次，且必须放在最后：反复调会触发无意义的底层 copy；调完就不能再写，Builder 也不再可复用（
只重置长度，不清理底层数组）
和
什么时候用
不是万能胶，只适用于「所有片段已就绪 + 同一分隔符」场景：
适用：
，内部已做最优预分配，比手写 Builder 循环快 10%～20%
不适用：边查 DB 边拼 CSV 行——先 append 到 slice 再 Join，slice 自身扩容开销可能反超 Builder；传
会 panic，空 slice + 非空分隔符返回空字符串
大多数时候没必要选：
仅当需要后续调
（写文件/网络）、或已混用
、或必须兼容 Go 1.9 时才考虑
它
每次都做 copy，接口更重，还带锁（虽不常触发），性能略低于
容易被忽略的关键点
预分配不是可选项，是必选项；
不是“取结果”，而是“锁定结果”——调完 Builder 就进入只读状态，不能再写，也不能靠
安全复用（它不清空底层数组，误复制会 panic）；高频路径上别信“小数据无所谓”，100 次和 10000 次的差异是线性放大的。
strings.BuilderGrow()+=+=result += sruntime.mallocgcfor _, line := range lines { log += line + "\n" }sql := "SELECT "; for _, f := range fields { sql += f + ", " }"GET " + path + " HTTP/1.1"+=strings.Builder[]byteWriteString()b.Grow(estimatedTotalLen)b.Grow(2048)b.WriteString(s)b.WriteRune(r)+=fmt.Fprintf(&b, ...)b.String()Reset()strings.Joinbytes.Bufferstrings.Joinstrings.Join([]string{"a", "b", "c"}, ",")nilbytes.Bufferb.Bytes()fmt.Fprintf(&b, ...)String()strings.BuilderString()Reset()