bytes.Buffer 为什么不是“高性能”默认选项
直接说结论：bytes.Buffer 本身不带内存复用，每次新建都分配新底层数组，高频创建会触发频繁 GC，尤其在 HTTP 中间件、日志拼接、序列化等场景下容易成为瓶颈。
它适合单次、短生命周期、不确定写入量的场景（比如临时拼个错误信息），但不适合每请求都 new 一个的循环使用模式。
- 默认初始容量是 0，第一次
Write就要扩容，至少一次内存分配 -
Reset()只清空读写位置，不释放底层[]byte，反复用会导致内存只涨不跌 - 没有并发安全设计，多 goroutine 同时
Write必须加锁，一加锁就抵消了大部分性能优势
sync.Pool 复用 bytes.Buffer 的正确姿势
复用的关键不是“放进去再取出来”，而是控制对象生命周期与归还时机——必须确保归还时 Buffer 内容已无敏感数据，且未被其他 goroutine 引用。
典型错误是：写完直接 pool.Put(buf)，但下游代码可能还在读 buf.Bytes() 返回的切片，造成数据错乱或 panic。
立即学习“go语言免费学习笔记（深入）”；
- 归还前务必调用
buf.Reset()，清空buf.buf的读写偏移，避免下次取出时残留旧数据 - 绝不能归还正在被
Bytes()或String()持有底层切片引用的Buffer - 推荐封装成函数，统一构造 + 归还逻辑，例如：
func getBuf() *bytes.Buffer { b := pool.Get().(*bytes.Buffer) b.Reset() return b } func putBuf(b *bytes.Buffer) { pool.Put(b) }
Pool.New 初始化函数里不能用 make([]byte, 0, 64)
看似合理：预分配小缓冲，减少后续扩容。但这是陷阱——bytes.Buffer 的底层字段 buf []byte 是私有的，外部无法直接设置；如果在 New 里 return &bytes.Buffer{buf: make([]byte, 0, 64)}，实际无效，因为 bytes.Buffer 的构造逻辑不认这个字段（Go 1.20+ 已明确忽略）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
真正生效的方式只有两种：
- 调用
bytes.NewBuffer(make([]byte, 0, 64))，传入预分配切片（此时buf字段会被正确初始化） - 或用
&bytes.Buffer{}+ 后续Grow()，但不如前者干脆 - 注意：
make([]byte, 64)（非零长度）会导致 Buffer 初始len(buf)==64，Bytes()会返回全零内容，容易引发逻辑 bug
为什么不用 strings.Builder 替代
strings.Builder 确实更轻量、零拷贝、无并发问题，但它只能写 string 和 []byte（需转成 string），不支持读取中间状态、不支持 ReadFrom、也不支持像 bytes.Buffer 那样当 io.Reader/io.Writer 透传使用。
典型不兼容场景：
- HTTP handler 中需要把响应体先写进 buffer，再用
http.ServeContent流式返回 ——strings.Builder没有io.Reader接口 - 调用第三方库函数，参数类型固定为
io.Writer，而你手头只有 builder —— 不能直接传 - 需要反复
WriteTo(io.Writer)多次（如写 socket + 写日志），Builder没有重置后复用的公开方法
所以选型不是“谁更快”，而是“谁满足接口契约”。一旦涉及 io 接口流转，bytes.Buffer + sync.Pool 仍是不可替代的组合。
最常被忽略的一点：Pool 的对象可能被 GC 回收，所以不能假设每次 Get() 都拿到干净实例——Reset() 不是可选动作，是必做动作。
