bytes.Buffer适合内存内小到中等规模一次性拼接或读写，不适合流式大文件、全局复用或并发场景；String()安全不可变，Bytes()返回可变底层数组需谨慎拷贝；Reset()彻底重用缓冲，Truncate(0)仅逻辑截断；非UTF-8或需底层IO时必须用bytes.Buffer而非strings.Builder。
bytes.Buffer 什么时候该用，什么时候不该用
直接说结论：bytes.Buffer 适合「内存内、小到中等规模、一次性拼接或读写」的字节操作；不适合流式大文件处理、长期复用的全局缓冲池、或需要并发安全的场景。
它底层是切片扩容机制，Grow() 和 Write() 都可能触发 append，频繁小写入会多次 realloc；但如果你只是拼个 JSON 字符串、构造 HTTP 请求体、或者临时解析一段二进制协议头，它比 string + 高效得多，也比手动管理 []byte 简洁。
- 别用在 for 循环里反复
NewBuffer(nil)—— 分配成本不低，改用Reset() - 别把它当
sync.Pool用：它本身不带并发保护，多 goroutine 同时Write()或String()会 panic 或读到脏数据 - 超过几 MB 的内容，优先考虑
io.Pipe或分块写入os.File，避免内存尖峰
为什么 String() 和 Bytes() 返回值行为不同
String() 返回的是底层数组的字符串视图，安全、不可变；Bytes() 返回的是可寻址的 []byte 切片 —— 这意味着你拿到的可能是 Buffer 内部缓冲区的直接引用。
常见错误现象：buf.Bytes() 拿到后缓存又被 Write()，导致原切片内容被覆盖；或者把 Bytes() 结果传给异步函数，而主流程后续又调了 Reset()，结果对方读到空或乱码。
立即学习“go语言免费学习笔记（深入）”；
- 需要只读副本？用
append([]byte{}, buf.Bytes()...)显式拷贝 - 确定生命周期可控、且不会二次修改？才直接用
buf.Bytes() - 想转成字符串又怕分配？
unsafe.String()在 Go 1.20+ 可用，但仅限你确认底层数组未被复用（比如刚Reset()过、只写过一次）
Reset() 和 Truncate(0) 的区别在哪
两者都清空当前内容，但语义和性能有差异：Reset() 会把长度置 0，并把底层 buf 切片指针重置为初始位置；Truncate(0) 只改长度，保留原有底层数组容量和数据（只是标记“不可见”）。
实际影响在于：如果之前写入很大内容导致切片扩容，Reset() 后下次写入仍可能复用原底层数组，而 Truncate(0) 之后如果紧接着 Grow(n)，Go 会按需检查是否已有足够容量 —— 多数情况没差别，但极端下 Truncate(0) 可能意外保留巨量闲置内存。
- 明确要“彻底清理并准备重用” → 用
Reset() - 只是临时截断到某位置（比如解析协议时跳过前 N 字节）→ 用
Truncate(n) - 从不手动设
buf.buf = nil—— 这会破坏Reset()的复用逻辑，反而触发新分配
和 strings.Builder 对比，什么情况下必须选 bytes.Buffer
strings.Builder 是 bytes.Buffer 的轻量替代，专为 UTF-8 字符串拼接优化，但不支持任意字节操作。一旦你需要处理非 UTF-8 数据（如 protobuf 编码、加密密文、图片 header）、或需要 ReadFrom(io.Reader)、WriteTo(io.Writer)、UnreadByte() 这类底层 IO 方法，就必须用 bytes.Buffer。
另一个关键点：strings.Builder 的 String() 不分配新内存（直接返回内部切片），但 bytes.Buffer.String() 总是分配 —— 如果你在 hot path 里高频调用且已知内容是合法 UTF-8，strings.Builder 更省 GC 压力。
- 拼 HTML 模板、日志消息、SQL 查询 →
strings.Builder更合适 - 序列化二进制结构体、构造 TCP 包、解析 gzip 流 → 必须
bytes.Buffer - 混用字符串和 raw bytes？别硬凑，先
[]byte(s)转换再写入bytes.Buffer，别依赖隐式转换
bytes.Buffer 当作“万能字节容器”，却忘了它没有上下文感知能力 —— 它不知道你写进去的是 base64、是 hex、还是加密后的垃圾数据。边界判断、编码校验、生命周期管理，全得你自己兜底。 
