循环拼接必须用strings.Builder并显式调Grow()，禁用+=；因字符串不可变，+=导致O(n²)拷贝和GC飙升；已知切片优先用strings.Join；bytes.Buffer仅适用于需Bytes()或兼容旧版等特定场景。
循环拼接必须用 strings.Builder，禁用 +=
Go 字符串不可变，s += "x" 每次都新建底层数组、全量拷贝旧内容。1000 次拼接实际拷贝字节数是 O(n²) 级别，压测显示比 strings.Builder 慢 3–5 倍，内存分配多一个数量级。
常见错误现象：pprof 显示大量 runtime.makeslice 和高频小对象分配，GC 明显抖动。
适用场景仅限编译期可知的 ≤3 段拼接，比如 "GET " + path + " HTTP/1.1"——此时编译器会优化成单次分配。一旦进入循环、重试逻辑或批处理，+= 就该立刻替换。
strings.Builder 必须调 Grow() 才真正快
strings.Builder 底层复用 []byte，但默认初始容量为 0。不预估就等于白用：首次 WriteString 触发分配，后续扩容多次 append，抵消性能优势。
立即学习“go语言免费学习笔记（深入）”；
-
b.Grow(n)是“确保还能写入至少n字节”，不是“设容量为n”；传 0 或负数无害但无效 - 预估总长宁可略高估（如乘以 1.5），别依赖默认值
- 别在循环里反复调
Grow()，应在拼接前一次性估算并调用 - 实测拼 10 个 128 字节字符串，
b.Grow(1500)比不调快 15%～20%，分配次数从 3 次降到 1 次
别把 fmt.Sprintf 当拼接工具塞进循环
fmt.Sprintf 是格式化工具，不是拼接工具。它内部有格式解析、反射缓存管理等开销，哪怕只拼两个字符串，也比 strings.Builder 慢 2.5 倍以上，且稳定分配 40+ 字节内存。
典型误用：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
b.WriteString(fmt.Sprintf("%d", x))：格式化白费，还多一次内存分配 - 循环中写
line = fmt.Sprintf("%s,%d,%t", u.Name, u.ID, u.Active)：性能黑洞
正确做法：
- 整数用
strconv.AppendInt(b.AvailableBuffer(), x, 10)直接写入底层切片，再手动更新长度 - 分隔符用
b.WriteByte(',')，零分配 - 纯拼接（无
%动词）就别绕远路
strings.Join 比手写 Builder 更省心也更快
strings.Join 内部就是用 strings.Builder 实现的，还自带最优预分配逻辑，适合「所有片段已就绪 + 同一分隔符」场景。
适用：strings.Join([]string{"a", "b", "c"}, ",")，性能比手写 Builder 循环快 10%～20%
不适用：边查 DB 边拼 CSV 行——先 append 到 []string 再 Join，slice 自身扩容开销可能反超直接 Builder 流式写入
注意：strings.Join(nil, ",") 会 panic；空切片可以，但不能传 nil
真正容易被忽略的是：预估容量时，很多人按“平均长度 × 元素数”算，却忘了分隔符、前缀后缀、转义字符这些固定开销。日志行拼接漏掉时间戳长度、JSON 构建漏掉引号和冒号，都会让 Grow() 失效，触发扩容。宁可多留 20% 余量，也别卡着算。
