高频拼接字符串时不能用 +=，因go中字符串不可变，每次拼接都需全量复制旧内容并分配新内存，1000次循环可能触发上千次堆分配和gc；而bytes.buffer复用底层[]byte，仅扩容5–10次，配合grow()预分配可显著减少拷贝。
高频拼接字符串时，直接用 + 或反复 fmt.Sprintf 会触发大量内存分配，GC 压力陡增；bytes.Buffer 是最常用且足够稳的选择，但得知道怎么用才不踩坑。
为什么不能用 string += 拼接高频字符串
Go 中 string 不可变，每次 s += "x" 都要复制整个旧内容到新内存。1000 次循环可能分配上千次堆内存，而 bytes.Buffer 通常只扩容 5–10 次——不是“语法更短”，是底层行为完全不同。
-
+=每次都生成新对象，旧字符串等 GC 回收；bytes.Buffer复用内部[]byte，只在容量不足时扩容 - 压测时
pprof里能看到runtime.mallocgc占比飙升，基本就是这个信号 - 哪怕只是日志拼接、HTTP body 组装、SQL 参数注入这类“小操作”，一旦进循环或高频路径，就立刻暴露
bytes.Buffer 的正确初始化与预扩容
buf.Grow(n) 不是可选项，而是高频场景下的必做动作。它提前预留空间，避免写入过程中反复扩容拷贝。
- 估算总长度：比如拼 JSON，字段名+引号+逗号+base64 编码后 payload 长度，加个 buffer（如 +128）
-
Grow不保证精确，但能显著减少扩容次数；没调用也行，只是性能波动更大 - 别用
bytes.NewBuffer(make([]byte, 0, n))初始化——这看似预分配，但内部 offset 和 len 逻辑容易误判，不如直接var buf bytes.Buffer+Grow
WriteString vs Write：什么时候该用哪个
两者底层共用同一段追加逻辑，但语义和使用习惯不同。
-
WriteString接收string，适合拼接常量、变量名、格式化时间等已知字符串 -
Write接收[]byte，适合直接写入io.Read返回的切片、加密结果、或已有的字节数据，省去[]byte(s)转换（虽然 Go 运行时做了零分配优化，但明确语义更安全） - 混合使用没问题：
buf.WriteString("key:")+buf.Write(data)+buf.WriteByte('\n')
buf.String() 和 buf.Bytes() 的陷阱
返回值不是副本，而是对内部缓冲区的“视图”，这点必须心里有数。
-
buf.String()返回的是只读string，安全；但后续再写入会复用底层数组，所以不要缓存这个字符串并长期持有 -
buf.Bytes()返回的是内部[]byte切片，如果之后继续Write，它的内容可能被覆盖——常见错误是data := buf.Bytes(); buf.Reset(); process(data)，这时data已失效 - 需要稳定字节切片时，显式拷贝：
copyBuf := append([]byte(nil), buf.Bytes()...)或dup := append([]byte{}, buf.Bytes()...)
Buffer 不是万能胶，它解决的是“单 goroutine 内顺序写入+一次性消费”的场景；如果需要并发写、或中间多次读取、或流式转发，就得考虑 sync.Pool 管理 Buffer 实例，或者换用 strings.Builder（只支持 string，更轻量）——但绝大多数 HTTP 构造、日志、模板填充，bytes.Buffer 加合理 Grow 就够用，关键是别把它当黑盒，得看清它返回的 Bytes() 是谁家的地。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
