bytes.Buffer 是可读可写的动态缓冲区，适合需拼接后读取的场景；bytes.Reader 是只读零拷贝封装器，适用于静态数据的一次性或可寻址读取。
bytes.Buffer 和 bytes.Reader 的核心区别在于：**前者是可读可写的内存缓冲区，后者是只读、不可修改的字节切片封装器**。选错类型会导致编译失败（比如想 Write 却用了 Reader），或隐性性能浪费（比如该用 Reader 零拷贝读取时却误建 Buffer）。
什么时候该用 bytes.Buffer？看是否需要「动态拼接 + 后续读取」
典型场景：构建 HTTP 响应体、格式化日志、组装二进制协议头、替代字符串拼接避免频繁内存分配。
-
Buffer实现了io.Writer和io.Reader，能边写边读，且写入后自动扩容 - 创建后可反复调用
WriteString、WriteByte、Fprintf等，最后用Bytes()或String()提取结果 - 注意：
String()返回的是当前未读部分的副本；多次调用Read会移动内部读取偏移，影响后续String()结果 - 错误用法示例：把只读数据传给
bytes.NewBuffer再试图“重置内容”，不如直接用Reader
buf := bytes.NewBuffer(nil)
buf.WriteString("hello")
buf.WriteByte(' ')
buf.WriteString("world")
fmt.Println(buf.String()) // "hello world"
// ✅ 正确：写完再读
什么时候该用 bytes.Reader？看是否只是「一次性/可 Seek 的只读访问」
典型场景：将静态配置字节切片转为 io.Reader 供函数消费（如 json.NewDecoder）、测试中模拟网络流、需要 Seek 回退解析位置。
-
Reader底层不复制数据，Read是零拷贝视图操作，内存友好 - 它实现了
io.Reader和io.Seeker，但**没有Write相关任何方法**，尝试调用会编译报错 - 初始化后长度固定，
Len()返回剩余可读字节数，Size()返回原始总长 - 常见坑：误以为
Reader能“缓存写入”，结果发现没有Write方法，只能换Buffer
data := []byte("config.json: {\"port\":8080}")
r := bytes.NewReader(data)
var cfg struct{ Port int }
if err := json.NewDecoder(r).Decode(&cfg); err != nil {
log.Fatal(err)
}
// ✅ 正确：纯读取，无修改需求
WriteTo 和 ReadFrom 的归属差异决定 I/O 流向设计
这两个方法是判断类型角色的关键信号：只有 Buffer 有 ReadFrom（从外部读进自己），只有 Buffer 有 WriteTo（把自己写出到外部）。Reader 完全不具备主动输出能力。
-
buf.ReadFrom(r io.Reader)：高效地把任意io.Reader（如文件、HTTP body）流式写入Buffer，避免中间切片分配 -
buf.WriteTo(w io.Writer)：把整个缓冲区内容一次性刷到目标（如os.Stdout、网络连接），比循环Write更快 -
bytes.Reader没有对应方法——它只负责“被读”，不参与数据流入或流出的控制权
性能与安全边界：别让 Buffer 成为内存黑洞
Buffer 动态扩容虽方便，但无上限增长可能引发 OOM；Reader 则天然受控——它只反映已有切片长度。
立即学习“go语言免费学习笔记（深入）”；
-
Buffer默认初始容量 0，写入时按需翻倍扩容（类似 slice），大量写入小块数据易触发多次 realloc - 生产环境建议：预估大小，用
bytes.NewBuffer(make([]byte, 0, expectedCap))避免抖动 -
Reader不分配额外内存，但若底层切片本身很大（如加载了整个 GB 级配置文件），Reader只是持有引用，不会减轻内存压力 - 并发使用二者都需加锁——它们都不是线程安全的，这点常被忽略
Buffer 的“读写指针分离”特性**。写入永远追加到末尾，但读取从开头开始、并随 Read 移动；而 Reader 的读取偏移也移动，但无法写入重置。一旦在逻辑中混淆了“已读/未读/已写”区域，String() 或 Bytes() 就会返回意料之外的片段。 
