循环拼接字符串必须用strings.Builder并显式Grow()，否则性能差200倍以上；因字符串不可变，+=每次分配新数组并复制旧内容，导致GC飙升和延迟毛刺。
循环内拼接字符串必须用 strings.Builder 并显式调用 Grow()，否则性能可能差 200 倍以上；+= 在高频路径上不是“慢一点”，而是直接触发 GC 飙升和非线性延迟毛刺。
为什么 += 在循环里是性能断崖
Go 字符串不可变，每次 result += s 都要分配新底层数组、复制全部旧内容。1000 次拼接 ≈ 1000 次内存分配 + 至少几十 MB 无效拷贝，pprof 里满屏 runtime.mallocgc 就是它在作祟。
典型错误现场：
for _, line := range lines { log += line + "\n" }sql := "SELECT "; for _, f := range fields { sql += f + ", " }
小量固定拼接（如 "GET " + path + " HTTP/1.1"）没问题——编译器能静态合并；但只要进循环、或拼接次数不确定，+= 就该立刻替换。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
怎么正确用 strings.Builder
它快，是因为底层复用 []byte，WriteString() 是均摊 O(1)；但它默认初始容量为 0，不预估就等于白用。
- 必须调
b.Grow(estimatedTotalLen)：知道总长？直接传值（如b.Grow(2048)）；不知道？按场景经验预估（日志行 ≤512B，HTML 片段 ≤4KB），宁大勿小 - 只用
b.WriteString(s)或b.WriteRune(r)：+=会报错，fmt.Fprintf(&b, ...)多一层格式解析，慢 3–5 倍 -
b.String()只调一次，且必须放在最后：反复调会触发无意义的底层 copy；调完就不能再写，Builder 也不再可复用（Reset()只重置长度，不清理底层数组）
strings.Join 和 bytes.Buffer 什么时候用
strings.Join 不是万能胶，只适用于「所有片段已就绪 + 同一分隔符」场景：
- 适用：
strings.Join([]string{"a", "b", "c"}, ",")，内部已做最优预分配，比手写 Builder 循环快 10%～20% - 不适用：边查 DB 边拼 CSV 行——先 append 到 slice 再 Join，slice 自身扩容开销可能反超 Builder；传
nil会 panic，空 slice + 非空分隔符返回空字符串
bytes.Buffer 大多数时候没必要选：
- 仅当需要后续调
b.Bytes()（写文件/网络）、或已混用fmt.Fprintf(&b, ...)、或必须兼容 Go 1.9 时才考虑 - 它
String()每次都做 copy，接口更重，还带锁（虽不常触发），性能略低于strings.Builder
容易被忽略的关键点
预分配不是可选项，是必选项；String() 不是“取结果”，而是“锁定结果”——调完 Builder 就进入只读状态，不能再写，也不能靠 Reset() 安全复用（它不清空底层数组，误复制会 panic）；高频路径上别信“小数据无所谓”，100 次和 10000 次的差异是线性放大的。
