bytes.buffer是可读写内存缓冲区，非字节转换工具；写字符串优先用writestring避免拷贝，bytes()返回可修改底层数组引用，string()返回安全只读副本，复用须reset()并注意游标重置与嵌入字段生命周期管理。
bytes.Buffer 不是字节转换工具，它是可读写的内存缓冲区；所谓“转换”，实际是写入、读取、视图提取三个动作的组合，错用 Bytes() 或 String() 就会出数据污染或 panic。
WriteString 和 Write 的选择逻辑
写字符串时别先转 []byte 再调 Write，这多一次内存拷贝，还绕过 WriteString 的零分配优化。Go 运行时允许直接读取字符串底层字节数组，WriteString 就是为此设计的。
- 已知是字符串 → 无条件用
WriteString - 已有
[]byte变量（比如从网络读来的原始包体）→ 用Write - 不要为“统一接口”把
s强转成[]byte(s)后传给Write，这是典型性能陷阱
String() 和 Bytes() 返回值能不能改
String() 返回的是只读副本，安全但有 UTF-8 校验开销；Bytes() 返回的是内部底层数组的直接引用——改它等于改 Buffer 自己的内容。
- 需要最终输出或日志打印 → 用
String() - 要零拷贝传给
syscall.Write或os.File.Write→ 用Bytes()，但之后绝不能再调Write、Reset()或Grow() - 既要稳定切片又要继续写 → 必须
copy(dst, buf.Bytes())拷一份，不能省 - Go 1.20+ 若确认刚
Reset()过且只写过一次，可用unsafe.String()避免分配，但别在热路径里默认启用
复用 bytes.Buffer 时为什么内存不降反涨
Reset() 只清长度、重置读写偏移，底层数组容量（cap）完全保留。如果某次写入了 8MB，之后每次 Reset() 复用，它仍占着 8MB 底层空间。
- 高频小写入 + 历史大写入 → 池中对象会滞留巨量闲置内存
- 想真正缩容？只能新建：
buf = *bytes.NewBuffer(make([]byte, 0, 128)) - 嵌入结构体字段时，
Reset()不会自动调用，必须显式管理，否则旧数据残留可能引发 HTTP 响应体重复、协议解析错位等静默 bug - 用
sync.Pool管理*bytes.Buffer时，归还前建议buf.Truncate(0); buf.Grow(64)主动收缩，避免池被大容量实例污染
写完就读不出内容？其实是游标没重置
bytes.Buffer 的读写共享同一个内部游标（off 字段）。写完后游标停在末尾，此时调 Read()、ReadBytes('\n') 或 io.ReadAll(&buf) 全部返回空，不是 Buffer 没数据，是“读位置不在开头”。
- 想一次性拿全部内容 → 直接用
buf.Bytes()或buf.String()，它们不依赖游标 - 想在 Buffer 上继续做流式读取（比如解析 HTTP header）→ 必须先
buf.Seek(0, 0)或buf.Reset()再重写 - 边写边读场景 → 优先用
buf.Next(n)、buf.ReadByte()，它们自动推进游标，无需手动 Seek
最常被忽略的一点：当 bytes.Buffer 作为结构体字段嵌入时，它的生命周期不再由作用域自动管理；Reset 必须显式、及时、成对出现，否则上一轮残留的数据会在下一轮被意外拼接进去——这种 bug 往往只在高并发或特定数据长度下才暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
