用 strings.Builder 拼接大量字符串最稳
Go 里拼接字符串，+ 看似简单，但每次都会分配新内存、复制旧内容，100 次拼接可能触发几十次内存分配。真正要拼接动态内容（比如日志组装、HTML 模板生成、SQL 构建），strings.Builder 是标准库给出的明确答案——它内部用切片预扩容，写入过程零拷贝。
常见错误是只在小循环里图省事用 +=，结果压测时 GC 飙升；或者误以为 fmt.Sprintf 能“优化”，其实它底层还是先格式化再分配字符串，开销更大。
- 初始化时如果知道大致长度，直接传参：
var b strings.Builder; b.Grow(1024)，避免多次底层数组扩容 - 写入用
b.WriteString(s)或b.WriteRune(r)，别用b.WriteString(fmt.Sprint(x))—— 这等于绕路调了 fmt 再写 - 最终取结果只调一次
b.String()，别反复调，它每次都会新建字符串
fmt.Sprintf 适合格式化，不适合拼接循环体
fmt.Sprintf 的定位是“带格式的值转字符串”，不是拼接工具。它内部会做反射、类型检查、缓存复用等，单次调用没问题，但放进 for 循环里就是性能黑洞。尤其当参数含接口类型（如 interface{}）时，逃逸分析容易让整个字符串堆分配。
典型误用场景：遍历 slice 拼 CSV 行，每行都写 fmt.Sprintf("%s,%d,%t", a, b, c)；正确做法是用 strings.Builder + 手动写分隔符，或改用 fmt.Fprint 写到 io.Writer。
立即学习“go语言免费学习笔记（深入）”；
- 适合用
fmt.Sprintf的地方：错误信息构造（fmt.Sprintf("failed to parse %q: %v", input, err)）、调试日志、固定模板的一次性渲染 - 参数尽量是具体类型（
string,int），避免传any或空接口，减少反射开销 - 如果必须批量格式化，考虑预分配
[]string存结果，最后用strings.Join
strings.Join 只适合已知切片的拼接
当你已经把所有片段存在 []string 里，strings.Join 是最简洁高效的选择。它一次算总长、一次分配、一次拷贝，没有 Builder 的初始化成本，也没有 + 的重复分配问题。
但它的前提是“所有片段已就绪”。有人试图先 append 到 slice 再 join，却在循环里反复 append 导致 slice 频繁扩容，整体性能反而不如 Builder。这时候就不是 Join 的问题，而是数据组织方式错了。
- 适用场景：配置项列表转逗号串、路径组件拼接（
strings.Join([]string{"api", "v1", "users"}, "/")）、HTTP Header 值合并 - 注意
sep参数是 string，别传 rune 或 byte；空 slice + 非空 sep 返回空字符串，不是 panic - 如果片段来自 map 遍历，记得先排序 key 或转成有序 slice，否则结果不稳定
Builder 不是万能的：小心接口隐式转换和逃逸
strings.Builder 底层是 []byte，所以它实现了 io.Writer，可以传给 json.Encoder、template.Execute 等接受 io.Writer 的函数。但这里有个坑：一旦你把它当作 io.Writer 传进函数，而那个函数又把指针存起来（比如注册回调），就会导致整个 Builder 逃逸到堆上——哪怕你本意只是局部拼接。
另一个隐形成本是：Builder 的 WriteString 接口接收 string，但 Go 字符串头是只读的；如果你传的是从大字符串截取的小子串（比如 s[100:105]），底层仍持有原底层数组引用，可能阻止大内存释放。
- 避免把 Builder 地址传给生命周期不确定的函数；需要时显式用
bytes.Buffer替代（它更重，但语义更清晰） - 若拼接内容来自大字符串切片，先
string([]byte(s))强制复制，切断底层数组引用 - benchmark 时别只测 CPU，加
-gcflags="-m"看逃逸分析，Builder 在栈上分配才是理想状态
