strings.builder是首选因其底层复用[]byte、零拷贝追加，但不预估容量就等于白用；未调grow()会触发多次扩容，性能仅比+=好20%，而合理调用grow(n)可将内存分配次数降至1次、耗时减半、内存降为1/4。
循环拼接必须用 strings.Builder，且一定要调 Grow()；+ 只适用于 ≤3 段、编译期完全可知的静态拼接（比如 "GET " + path + " HTTP/1.1"），其他场景用 + 就是给 GC 添堵。
为什么 strings.Builder 是首选，但不预估容量就等于白用
strings.Builder 底层复用 []byte，写入不分配新字符串，也不做 UTF-8 验证，零拷贝追加——但它默认初始容量为 0。没调 Grow() 就直接写，和 bytes.Buffer 一样会触发多次翻倍扩容，实测性能可能只比 += 好 20%。
- 知道总量？比如拼 500 行日志，每行平均 128 字节 →
b.Grow(500 * 128) - 不确定但有量级？宁可设大点：预期几 MB，直接
b.Grow(4 （4MB） - 别用
len(s) + len(t) + ...硬算再传进去——如果中间有WriteRune或WriteByte，UTF-8 多字节字符会让长度变数，预留时多加 10% 更稳
bytes.Buffer 和 strings.Builder 到底选哪个
绝大多数场景下，strings.Builder 更轻、更快、更安全：它禁止读取未写入部分，不会意外暴露底层切片；bytes.Buffer 提供 Bytes() 和 String() 两种返回方式，但 Bytes() 返回的是可变底层数组，若后续还写入，之前拿到的 slice 就会变 —— 这是常见静默 bug 来源。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 只要最终要 string → 无脑用
strings.Builder - 需要把 buffer 直接传给
io.Writer（如写文件、HTTP 响应）→bytes.Buffer的WriteTo(w)是零拷贝，strings.Builder不支持 - 要并发写？两个都不行 —— 它们都非线程安全，得自己加锁或每个 goroutine 独占一个实例
String() 调一次就够了，别在循环里反复调
b.String() 每次都分配新内存、完整拷贝底层数组。如果你在循环里边写边调，比如日志聚合时每拼一行就 fmt.Println(b.String())，那 Builder 的优势全被抵消，性能甚至不如 +=。
- 必须中途取值？用
b.Len()和b.Cap()查状态，别取内容 - 真要分段看？改用
bytes.Buffer+b.Bytes()（注意：只读，且确保之后不再写） - 最终输出前才调一次
b.String()—— 这是唯一合理时机
strings.Join 在什么情况下反而更慢
strings.Join 内部其实也用 strings.Builder，还带智能预分配逻辑，但它要求你先把所有片段塞进 []string。这个“塞”的过程本身就有开销：
- 边读文件边拼？先
append到切片 → 多次扩容 + 最后一次遍历拷贝 → 不如 Builder 流式写入 - 带条件过滤（比如跳过空字段）？得先遍历一遍生成切片，再遍历一遍 Join → 双倍 O(n)
- 只拼两个字符串？
strings.Join([]string{a, b}, "")多此一举，直接a + b或 Builder 更轻
真正适合 strings.Join 的，只有那种所有字符串已全部就绪、且用统一单一分隔符连接的场景，比如 strings.Join(headers, "\r\n")。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
