循环中字符串拼接禁用+=，应优先使用strings.builder并预调grow()；已知切片时用strings.join()更优；避免bytes.buffer除非需bytes()或兼容旧版。
循环里别用 +=，这是性能断崖的起点
Go 字符串不可变，每次 result += s 都得分配新内存、把旧内容全拷一遍。拼 1000 次，可能触发几百次 runtime.mallocgc，pprof 一眼看到满屏内存分配热点。
- 典型错误现场：
for _, s := range lines { log += s + "\n" } - 小量固定拼接（比如
"prefix" + name + ".txt"）没问题，编译器会优化成单次分配 - 只要拼接次数不确定、或在 HTTP handler / 日志中间件 / SQL 构建等高频路径里，
+=就该立刻替换
大量动态拼接，无条件选 strings.Builder 并调 Grow()
strings.Builder 是 Go 1.10+ 官方指定方案，底层复用 []byte，WriteString() 基本是零开销追加——但前提是别让它频繁扩容。
- 必须显式调用
b.Grow(estimatedTotalLen)，比如已知最终约 2KB，就传2048；不调的话默认容量为 0，第一次写就扩容，后续还可能翻倍增长 - 只用
b.WriteString(s)，别混用b.Write([]byte(s))或fmt.Fprintf(&b, ...)，后者多一层格式解析，纯拼接时慢 3–5 倍 -
b.String()只在最后调一次，它只是把底层数组转成 string header，零拷贝；反复调会触发无意义复制
已知所有片段？直接上 strings.Join()，别手写 Builder 循环
如果你的数据已经在一个 []string 里，比如从 map 提取的键、配置项列表、HTTP header 值集合，strings.Join() 不仅代码短，性能还比手写 Builder 略高 10%～20%，因为内部做了最优预分配。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 正确姿势：
result := strings.Join(parts, ",")，前提是parts是[]string类型 - 错误姿势：先
append到 slice 再Join，却在循环里没预分配 slice 容量，导致 slice 自身频繁扩容，整体更慢 - 注意：
strings.Join(nil, ",")会 panic，空切片可以，但不能传nil
什么情况下考虑 bytes.Buffer？其实大多数时候不用
bytes.Buffer 功能更全，支持读、Seek、WriteTo 等，但它不是为字符串拼接而生的——Buffer.String() 每次都做 copy，且接口带 error 返回，有轻微开销。
- 选
bytes.Buffer的真实理由只有三个：需要后续调 <code>buffer.Bytes()写入文件或网络、要复用缓冲区并调 <code>buffer.Reset()、或必须兼容 Go 1.9 及更早版本 - 如果只是拼完就输出，
strings.Builder更轻、更快、更安全（它有copyChecker，误复制会 panic，帮你提前发现问题） - 并发写同一个
strings.Builder会崩溃——它没锁，也没原子字段，这点和bytes.Buffer不同
真正难的不是选哪个 API，而是判断“拼接”是不是真的必要：比如日志场景，与其拼好再写，不如直接用 io.WriteString(w, s) 流式输出；比如数字拼接，strconv.AppendInt(buf, n, 10) 直接写进字节切片，比先转 string 再拼更省事。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
