strings.Builder 比 + 和 fmt.Sprintf 更快，因其底层使用可增长的 []byte 缓冲区，避免重复内存分配和格式解析开销；而 + 每次拼接都复制字节数组，fmt.Sprintf 既有解析成本又频繁分配新字符串。
为什么 strings.Builder 比 + 和 fmt.Sprintf 更快
因为 + 每次拼接都生成新字符串（底层复制字节数组），fmt.Sprintf 有格式解析开销且同样分配新字符串；而 strings.Builder 底层用可增长的 []byte 缓冲区，只在必要时扩容，避免重复内存分配。
典型场景：拼接 100+ 字段的日志行、生成 HTML 片段、构造 SQL 查询字符串。
-
strings.Builder在首次Write前不分配底层数组，适合不确定长度的拼接 - 调用
Grow(n)预估容量可减少扩容次数，但预估过大反而浪费内存 - 不要对
Builder做多次String()调用——它会触发一次拷贝，应只在最终结果处调用一次
怎么写一个可复用的高效拼接函数
别封装成通用“万能拼接函数”，而是按场景定制。例如拼接带分隔符的字符串列表，直接用 strings.Join；若需条件拼接或嵌套结构，用 strings.Builder 手动控制。
示例：拼接非空字段并用逗号分隔
立即学习“go语言免费学习笔记（深入）”；
func joinNonEmpty(fields ...string) string {
var b strings.Builder
for i, f := range fields {
if f == "" {
continue
}
if i > 0 {
b.WriteByte(',')
}
b.WriteString(f)
}
return b.String()
}
- 避免在循环内调用
b.String()或b.Len()（除非真需要） - 用
b.WriteString代替b.Write([]byte(s))，前者更直接 - 如果字段数量固定且少（≤3），
+反而更快，不用强行套Builder
基准测试必须覆盖真实使用模式
只测 “拼接 10 个固定字符串” 没意义。真实瓶颈往往来自缓冲区扩容、GC 压力或小对象逃逸。
关键测试点：
- 测试不同输入规模：10、100、1000 个字符串，观察是否出现性能拐点
- 混入不同长度字符串（如 1B、1KB、10KB），验证扩容策略是否合理
- 用
go test -benchmem看B/op和allocs/op，比单纯看 ns/op 更重要 - 避免在
Benchmark函数里定义闭包或局部 map——它们可能逃逸到堆，干扰结果
错误示范：func BenchmarkBad(b *testing.B) { for i := 0; i —— 这里 <code>s 不参与拼接，纯属干扰。
容易被忽略的逃逸和 GC 影响
即使用了 strings.Builder，如果返回值是 string，底层数组仍会被拷贝；但如果拼接结果要传给需要 []byte 的函数（如 json.Unmarshal），考虑直接暴露 Builder.Bytes() 并复用缓冲区。
- 用
go build -gcflags="-m"检查Builder是否逃逸——理想情况是栈上分配 - 高频调用场景下，可复用
strings.Builder实例（注意并发安全：它不是线程安全的） - 如果拼接后立即用于
io.WriteString或http.ResponseWriter.Write，优先用Builder.WriteTo避免中间string分配
复杂点在于：没有绝对“最高效”的写法，得看数据规模、调用频次、后续用途。盲目统一替换 + 到 Builder 可能反而增加维护成本和内存碎片。
