bytes.buffer不是万能字节拼接器，仅适合小到中等规模、内存内、一次性构建、顺序追加场景；复用必须调reset()而非赋值清空；读写共享游标，读前需seek(0,0)或用bytes()/string()；bytes()返回底层切片引用，修改会影响buffer自身。
bytes.Buffer 不是高性能默认选项，它本身不复用内存；高频创建会触发 GC，真正高性能靠的是预分配 + sync.Pool + 正确重置。
写完读不出？先搞清 off 游标在哪
写入后直接调 io.ReadAll(&buf) 返回空切片，不是 bug，是游标已到末尾。bytes.Buffer 的读写共用一个内部偏移量 off，Write 会把它推到结尾。
- 只取全部内容 → 用
buf.Bytes()或buf.String()，它们不依赖游标 - 要接着读（比如解析协议头）→ 必须先
buf.Seek(0, 0)或buf.Reset() - 边写边读（如流式解析）→ 用
buf.Next(n)、buf.ReadByte()，它们自动推进游标
复用 bytes.Buffer 别赋值清空，必须调 Reset()
写完一轮想再用，最常见错误是 buf = bytes.Buffer{} 或 buf = *new(bytes.Buffer)。这会丢弃已分配的底层数组，下次 Write 又得重新 malloc，GC 压力陡增。
-
Reset()是正解：清长度、重置off，但保留底层[]byte容量 - 如果曾写入 10MB，
Reset()后仍占 10MB 底层空间；真要缩容，只能新建：buf = *bytes.NewBuffer(make([]byte, 0, 128)) - 嵌入结构体时，
Reset()不会自动调用，必须显式管理生命周期，否则旧数据残留可能引发逻辑 bug
并发写入必须加锁，或改用 sync.Pool 每 goroutine 独立实例
bytes.Buffer 不是线程安全的。多个 goroutine 同时 Write、String、Reset 会触发数据竞争，导致 panic 或读到脏数据。
- 若必须共享单个实例 → 外层套
sync.Mutex，但一加锁就抵消大部分性能优势 - 更推荐方案 → 每个 goroutine 创建独立
bytes.Buffer，最后用bytes.Join合并 - 高频短生命周期场景（如 HTTP handler）→ 用
sync.Pool复用，但归还前必须Reset()，且不能归还正被Bytes()引用的实例
Bytes() 返回的是引用，改它等于改 buffer 自身
buf.Bytes() 返回的是底层切片的直接引用，不是拷贝。这点极易踩坑。
- 拿到
buf.Bytes()后传给异步函数，主流程又调Write()→ 对方读到被覆盖或乱码数据 - 仅需读取且不保留引用 → 用
buf.String()（安全只读，有 UTF-8 校验开销） - 需零拷贝传给
syscall.Write或os.File.Write→ 用buf.Bytes()，但必须确保后续不再写入 - 需要稳定切片又得继续写 → 先
copy(dst, buf.Bytes())拷贝出来，再Write()
真正影响性能的不是 buffer 本身多快，而是复用是否匹配真实请求分布——比如一次处理 1KB 日志和一次处理 1MB 协议包，用同一个池子反而导致大缓冲长期滞留。上线前务必用 pprof + runtime.ReadMemStats 看 Allocs 和 PauseNs 是否改善。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
