17370845950

应使用 strings.Builder 替代 += 拼接字符串，因其避免重复内存分配与拷贝；预调 Grow 可进一步提升性能；少量静态拼接（≤3 个）用 + 更快且零分配。

循环中拼接字符串，别用 +=

Go 的 string 是不可变的，每次 s += str 都会分配新内存、复制全部旧内容——100 次拼接，底层实际拷贝约 5000 次字节（O(n²) 复杂度）。压测显示，1000 次 += 循环比 strings.Builder 慢 3–5 倍，且分配次数爆炸式增长。

• ❌ 错误写法：

  var s string
  for _, v := range strs {
      s += v // 每次都新建 string
  }

• ✅ 正确做法：改用 strings.Builder，尤其配合 Grow 预估总长
• ? 场景判断：如果已知所有待拼接字符串（比如日志字段固定），优先转成 []string 后用 strings.Join，它一次性算好长度、只分配一次内存

strings.Builder 怎么用才不白搭性能？

Builder 本身快，但没预分配容量（Grow）时，内部 []byte 仍会多次扩容，带来隐性开销。实测在拼接 10 个 128 字节字符串时，builder.Grow(1500) 比不调用 Grow 快 15%～20%，分配次数从 3 次降到 1 次。

• ✅ 推荐写法：

  builder := strings.Builder{}
  builder.Grow(estimatedTotalLen) // 先估算总长度
  for _, s := range strs {
      builder.WriteString(s)
  }
  result := builder.String()

• ⚠️ 注意：Grow 是“至少预留”，不是“精确限制”；传 0 或负数无害但无效
• ? 不要混用：builder.Write([]byte(s)) 和 builder.WriteString(s) 效果一致，但前者多一次类型转换，没必要

什么时候直接用 + 反而最快？

编译器对静态或少量（≤3 个）字符串拼接做了深度优化：常量合并、单次分配。压测表明，s := a + b + c 在 Go 1.21+ 中比 strings.Join([]string{a,b,c}, "") 还快 10%～15%，且零分配。

• ✅ 安全场景：

  s := "HTTP/" + version + " " + statusCode + " " + statusText

  （固定 4 个变量，无循环）
• ❌ 危险场景：for i := 0; i —— 看似简洁，实为性能黑洞
• ? 判断技巧：如果所有操作数在编译期可知（或函数内确定数量/范围），+ 是最简最优解；否则一律交给 Builder 或 Join

fmt.Sprintf 和 bytes.Buffer 到底该不该碰？

fmt.Sprintf 本质是运行时格式解析 + 反射，哪怕只拼两个字符串，开销也远超纯连接。压测显示，它比 strings.Builder 慢 2.5 倍以上，且稳定分配 40+ 字节内存。bytes.Buffer 功能等价 Builder，但设计目标是字节流（如 HTTP body），返回 string() 时需额外拷贝；Builder 底层同为 []byte，但 String() 方法直接构造 string header，零拷贝。

• ✅ 唯一推荐用 fmt.Sprintf 的场景：需要类型自动转换 + 格式控制，例如 fmt.Sprintf("id=%d,name=%s", id, name)
• ? 避免用 bytes.Buffer 做纯字符串拼接：它没有 Grow 的语义友好接口，且 String() 有隐式拷贝
• ? 替代方案：含数字拼接时，用 strconv.AppendInt(builder.Grow(...), n, 10) 直接写入字节切片，比先转 string 再拼接快 30%+

真正卡住性能的从来不是“选哪个 API”，而是没意识到 string 不可变带来的链式分配代价。只要记住：循环拼接必用 Builder 并 Grow，固定小量拼接放心用 +，其余场景看是否已有切片——这三条，覆盖 95% 的真实需求。