bytes.buffer不适合大文件写入，因其将全部数据驻留内存，易致oom，且存在冗余拷贝、无并发安全、不可流式处理等问题；仅适用于几kb内小数据的单goroutine内存拼接。
为什么不该直接用 bytes.Buffer 做大文件写入
它不是为持久化设计的，所有数据都存在内存里。写入几百 MB 的日志或导出文件时，bytes.Buffer 会把整个内容缓存在 RAM 中，OOM 风险极高，而且多了一次「内存拼接 → 写磁盘」的冗余拷贝。
典型误用场景：先 buf.WriteString 累积大量内容，最后 os.WriteFile(filename, buf.Bytes(), 0644) —— 这等于把整块内存复制一遍再刷盘，既慢又危险。
- 缓冲区大小无上限，
Grow()触发多次底层数组扩容，有性能抖动 -
Bytes()返回的是内部切片引用，若后续继续写入，该切片可能被重用或覆盖（虽不常见，但非安全保证） - 无法流式处理：不能边生成边写磁盘，丢失了管道/网络场景下的低延迟优势
io.Copy + bytes.Buffer 适合什么场景
只适用于「小而确定」的中间构造：比如拼接 HTTP 响应头、生成短 SQL 模板、组装 JSON 片段等，总量可控在几 KB 内。
此时用 bytes.Buffer 比字符串拼接高效，又比临时开文件轻量。关键是要明确边界——它只是个内存里的“草稿本”，不是“落盘代理”。
- 推荐初始化时指定容量：
buf := bytes.NewBuffer(make([]byte, 0, 512))，避免小数据多次扩容 - 写完立刻用
buf.Bytes()或buf.String()消费，不要长期持有buf实例 - 别把它塞进
io.Copy(dst, &buf)当源——*bytes.Buffer实现了io.Reader，但读完就空了，且不可重放
真正需要流式写文件时，该用什么替代
绕过 bytes.Buffer，直接让数据流向 *os.File 或带缓冲的 bufio.Writer。这才是 Go 的惯用路径。
- 普通写入：用
f, _ := os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_APPEND, 0644)，然后f.Write()或f.WriteString() - 提升性能：包一层
bufio.NewWriter(f)，写完记得w.Flush()，否则内容可能滞留在缓冲区 - 需格式化输出：直接用
fmt.Fprintf(w, "key=%s value=%d", k, v)，w可以是*bufio.Writer或*os.File - 如果上游是
io.Reader（如 HTTP body、压缩流），直接io.Copy(f, r)，零拷贝转发
一个容易被忽略的坑：bytes.Buffer 不是线程安全的
它没有锁，也没有原子字段。多个 goroutine 同时调用 WriteString 或 Bytes()，结果未定义——可能 panic，也可能静默损坏数据。
即使你只在一个 goroutine 里写、另一个里读，也必须自己加同步，因为 bytes.Buffer 的读写共享同一片底层数组和 off 字段。
- 并发场景下，优先选
sync.Pool复用bytes.Buffer实例，而不是共享单个实例 - 更稳妥的做法是改用
strings.Builder（只支持字符串写入，无并发问题，且零分配） - 若真要跨 goroutine 传递数据，用 channel 发送
[]byte或string，别传*bytes.Buffer
bytes.Buffer 最常被误当作“万能中转站”，但它真正的定位是「短生命周期、单 goroutine、小数据量」的内存拼接工具。一旦涉及文件落地，路径就该拐向 os.File 和 bufio.Writer。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
