bytes.buffer 不是线程安全的；多个 goroutine 并发调用 write、string、reset 等方法会导致数据竞争，引发 panic 或读取脏数据，应使用 sync.mutex 保护或为每个 goroutine 创建独立实例。
bytes.Buffer 是不是线程安全的
bytes.Buffer 本身**不是并发安全的**。多个 goroutine 同时调用 Write、String、Reset 等方法，可能触发数据竞争，导致 panic 或读到脏数据。
常见错误现象：fatal error: concurrent map writes（虽不直接操作 map，但内部 slice 扩容或字段读写可能被 race detector 捕获）；或者 String() 返回空字符串、截断内容、甚至 panic。
- 如果必须并发写入，优先用
sync.Mutex包裹bytes.Buffer实例 - 更推荐方案：每个 goroutine 创建独立
bytes.Buffer，最后用bytes.Join合并 - 避免在 defer 中调用
buf.Reset()后又继续写 ——Reset()清空但不释放底层内存，而后续写入可能和其它 goroutine 冲突
为什么 bytes.Buffer.WriteString 比 buf.Write([]byte(s)) 快
因为 WriteString 绕过了 []byte 类型转换开销，也避免了临时切片分配 —— 它直接按字节遍历 string 底层数据，写入 buffer 的 buf 字段。
实测在小字符串（WriteString 性能高 15%~30%，GC 压力更低。
立即学习“go语言免费学习笔记（深入）”；
- 只要写的是常量或变量 string，一律用
WriteString -
Write更适合处理已有的[]byte，比如从网络读取、解密结果、或复用 byte slice - 别为了“统一写法”强行把 string 转成
[]byte再传给Write—— 这会多一次内存拷贝
bytes.Buffer 的容量增长策略和内存浪费问题
bytes.Buffer 底层是 slice，扩容规则类似 append：当容量不足时，新容量 = cap * 2（若原 cap cap + cap/4（≥1024）。这会导致写入后长期持有远超实际需要的内存。
典型场景：一个 Buffer 累积写入 2MB 日志后调用 Bytes() 发送，但之后继续复用它写入几 KB 新内容 —— 此时底层数组仍占 2MB+。
- 用完立即
buf.Reset()只清空长度，不缩容；想真正释放内存，需手动重置：buf = *bytes.NewBuffer(make([]byte, 0, 128)) - 若预估最大大小，初始化时指定容量：
bytes.NewBuffer(make([]byte, 0, 4096)) - 对长生命周期、写入量波动大的 Buffer，定期检测
len(buf.Bytes()) / cap(buf.Bytes())比值，低于 0.25 时重建实例
替代方案：什么时候该换用 strings.Builder
如果只做字符串拼接（无二进制数据、不需 ReadFrom、不调用 WriteTo），strings.Builder 是更轻量、更明确的选择 —— 它禁止读操作，API 更窄，编译器可做额外优化，且底层同样不复制 string 数据。
但注意：它不能像 bytes.Buffer 那样实现 io.Reader 或 io.Writer 接口，也不支持 Grow、Next 等操作。
- 纯字符串拼接 → 用
strings.Builder，性能略优，语义更清晰 - 需要兼容
io接口（比如传给json.Encoder、http.ResponseWriter）、或混写 binary/string → 必须用bytes.Buffer - 别试图用
strings.Builder的String()结果再去[]byte()转换 —— 这会触发拷贝，失去优势
缓冲区复用和容量控制是实际压测中最容易被忽略的点，尤其在 HTTP 中间件或日志聚合这类长周期服务里，Buffer 不缩容会悄悄吃掉大量 RSS 内存。
