大文件写入卡顿主因是流控失效而非缓冲区溢出；应显式用io.copybuffer配1mb缓冲、bufio.writer设1mb大小并主动flush、writeat前预分配空间，sync.pool小缓冲反降性能。
大文件写入时不会发生“缓冲区溢出”（buffer overflow），但会因缓冲区配置不当引发内存暴涨、写入卡死或 broken pipe —— 本质是流控失效，不是 C 风格的越界写入。
io.Copy 默认 32KB 缓冲在 NFS/USB 上为何卡住
io.Copy 内部使用一个 32KB 的临时缓冲区，对本地 SSD 足够，但在 NFS、CIFS 或 USB 设备上，小块写入会触发高频 syscall 和 write timeout。实测中，连续 write(2) 调用失败后可能返回 broken pipe，或吞吐骤降至几 MB/s。
- 必须显式替换为
io.CopyBuffer(dst, src, buf)，不能只写io.Copy(dst, src) - 缓冲区建议设为
make([]byte, 1024*1024)（1MB）：NFS 场景下实测提速 3–5 倍 - 若
dst是http.ResponseWriter或管道，需加time.AfterFunc监控单次Write超时，防上游僵死拖住 goroutine
bufio.Writer 写大文件时 flush 不及时导致内存堆积
bufio.Writer 会暂存数据直到缓冲区满或显式调用 Flush()。若写入速率远高于底层 writer 处理能力（如慢盘、网络阻塞），缓冲区会持续扩容，最终吃光内存 —— 这不是 bug，是设计使然。
- 初始化时指定合理大小：
bufio.NewWriterSize(f, 1024*1024)（1MB），避免默认 4KB 频繁 flush - 每写完逻辑块（如一行、一个 JSON 对象）后主动调用
w.Flush()，不要依赖 defer - 若目标 writer 可能阻塞（如 HTTP 响应体），在
Flush()前加 context.WithTimeout 控制等待时间
os.File.WriteAt 在 ext4 上隐式同步拖慢写入
用 WriteAt 做随机写（如分块并行写入大文件）时，ext4 文件系统可能触发隐式 fsync，尤其当写入位置跨 block 边界或文件未预分配。结果是顺序写变随机写，性能跌一个数量级。
- 优先用顺序写：
file.Write()或io.CopyBuffer流式追加 - 若必须随机写，先用
file.Truncate(size)预分配空间，再WriteAt - 避免在循环中反复
WriteAt(offset, data)；改用内存映射syscall.Mmap（需谨慎处理平台兼容性）
sync.Pool 复用 []byte 缓冲区反而更慢的条件
sync.Pool 不是银弹。当缓冲区小（如 4KB）、生命周期极短（
- 仅在以下情况启用 Pool：
buf := bufPool.Get().([]byte)后使用 ≥100μs，或缓冲区 ≥64KB - 推荐固定大小池：
var bufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 1024*1024) }} - 每次归还前清空长度：
buf = buf[:0]，防止残留数据污染后续使用
真正危险的从来不是缓冲区大小本身，而是缓冲区生命周期脱离控制——比如忘记 Close() 导致 os.File fd 泄漏，或 bufio.Writer 未 Flush() 就丢弃，这些都会让内存占用悄无声息地滚雪球。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
