Buffer.WriteString() 通常更快，因绕过[]byte转换开销；但已有[]byte时应直接用Write()；Grow()不保证避免扩容，需合理预估容量；复用必须Reset()；Bytes()返回切片不可修改，否则破坏内部状态。
Buffer.Write() 和 Buffer.WriteString() 哪个更快？
多数情况下 Buffer.WriteString() 更快，尤其拼接纯字符串时。它绕过 []byte 转换开销，直接操作底层字节数组；而 Buffer.Write() 接收 []byte，对字符串需先调用 string([]byte) 或隐式转换，多一次内存视图切换。
但注意：如果手头已经是 []byte（比如从 io.Read() 读来的数据），别强行转成 string 再用 WriteString() —— 这反而多一次拷贝，直接 Write() 更干净。
- 拼接常量字符串、格式化结果（如
fmt.Sprintf后）→ 优先WriteString() - 拼接网络包、文件块、加密输出等原始字节 → 必须用
Write() - 混合场景（字符串 + 字节切片）→ 分开调用，不强求统一接口
为什么 Buffer.Grow() 不总能避免扩容？
Grow() 只是“建议”预留空间，并不保证后续写入一定不触发扩容。它的行为取决于当前 Buffer 的 len 和 cap 关系，以及你传入的大小是否真能被容纳。
典型误用：在 WriteString() 前反复调用 Grow(n)，却没考虑已有内容长度。例如缓冲区已含 100 字节，你只 Grow(50)，但要写 80 字节新字符串——仍会扩容。
立即学习“go语言免费学习笔记（深入）”；
- 正确做法：预估总长度，用
buffer = bytes.NewBuffer(make([]byte, 0, estimatedTotalSize))初始化 -
Grow()适合写入前“临时补足”，但得算清：需要增长量 = 目标写入长度 − (buffer.Cap()−buffer.Len()) - 过度
Grow()会造成内存浪费，尤其在复用Buffer（如放在sync.Pool）时更明显
复用 bytes.Buffer 时，Reset() 和重赋值哪个安全？
必须用 Reset()，不能靠 buffer = &bytes.Buffer{} 或 buffer = bytes.NewBuffer(nil)。后者只是让局部变量指向新对象，原 Buffer 实例的底层 []byte 可能还被其他代码引用或缓存，造成数据残留或并发冲突。
常见于 HTTP 中间件、日志收集器等长期存活的缓冲场景。若忘记 Reset()，上次写入的内容可能意外出现在下次响应里。
-
Reset()清空buf的读写位置（off归零），并保留底层数组供复用 - 配合
sync.Pool时，Get()后第一件事就是buf.Reset() - 不要依赖
buf.Len() == 0判断是否干净——Reset()才是唯一可靠方式
Buffer.Bytes() 返回的切片能直接修改吗？
不能。Buffer.Bytes() 返回的是底层字节数组的**可寻址视图**，修改它会影响后续写入，甚至破坏 Buffer 内部状态（比如把结尾的 \x00 改掉，Write() 可能覆盖错误位置）。
典型踩坑：把 Bytes() 结果传给 json.Unmarshal() 或 proto.Unmarshal()，然后顺手改了里面某个字段——下次 Write() 就可能写到被篡改的内存上，引发 panic 或静默错乱。
- 需要可变副本 → 用
append([]byte{}, buf.Bytes()...)或copy(dst, buf.Bytes()) - 只读解析 → 安全，但记得别在解析中途调用
Write()，否则Bytes()视图可能失效 - 想零拷贝传递？用
buf.Next(n)拿走一段，它返回的切片生命周期由你控制，且已从 buffer 移除
最易被忽略的一点：Buffer 不是线程安全的，哪怕只读地交替调用 Bytes() 和 Write()，在 goroutine 间也必须加锁或确保串行访问。
