strings.Builder 比 + 快，因其内部用可增长 []byte 缓冲区，避免每次拼接都新建字符串和拷贝；+ 在循环中频繁分配内存，而 Builder 仅在扩容时分配，且 WriteString/Write 零分配（不扩容时）。
strings.Builder 为什么比 + 快
因为 + 每次拼接都新建字符串，底层是不可变的字节数组拷贝；strings.Builder 内部用可增长的 []byte 缓冲区，只在容量不足时扩容，避免频繁分配和复制。
典型场景：循环中拼接上百次、日志组装、模板渲染前的字符串构建。
- 100 次拼接，
+可能触发 100 次内存分配；strings.Builder通常只分配 2–4 次（取决于初始容量） -
strings.Builder的WriteString和Write方法零分配（只要不扩容） - 注意：
Builder.String()会做一次最终拷贝（从[]byte到string），但仅一次
什么时候不能用 strings.Builder
当拼接逻辑极简单、次数极少（比如固定 2–3 次），或者拼接内容已知且编译期可确定时，+ 更直接，甚至编译器还能优化成常量。
- 例如：
"HTTP/" + version（version是const）可能被内联为单一字符串字面量 -
strings.Builder有初始化开销，单次拼接反而更慢 - 不能复用已调用过
Reset()的Builder实例去读取旧内容——它不保存历史，Reset()清空全部
strings.Builder 容量设置踩坑点
不设初始容量或估得太小，会导致多次 grow，抵消性能优势；估太大又浪费内存。
立即学习“go语言免费学习笔记（深入）”；
- 用
strings.NewBuilder(size)预分配，比如预估最终长度 512 字节，就传512 - 不确定长度时，宁可略高估（如乘以 1.5），也不要默认 0 —— 默认容量是 0，第一次
WriteString就要分配 -
Builder.Grow(n)是“确保还能写入至少 n 字节”，不是“设容量为 n”；它不会缩小已有缓冲区 - 别在循环里反复调用
Grow，应在拼接前一次性估算并调用
加号拼接在什么情况下依然合理
短字符串、静态拼接、调试打印、测试用例里快速构造值 —— 这些地方性能无关紧要，可读性优先。
- 例如：
fmt.Sprintf("user_id=%d, name=%s", id, name)比 Builder 更自然 -
log.Printf("failed to parse %s: %v", filename, err)不值得换 Builder - 如果拼接含大量
fmt.Sprintf或接口转字符串（如strconv.Itoa），瓶颈往往不在拼接本身，而在格式化过程
真正卡顿的地方，通常不是“怎么拼”，而是“要不要拼”——比如把本该流式写入 io.Writer 的内容先攒成大字符串再输出。
