直接用os.readfile/writefile处理高频小文件写入会导致吞吐量受限于系统调用和磁盘寻道；高吞吐需组合缓冲（bufio）、批处理（合并小io）和可控并发（worker pool）三类模式。
直接用 os.ReadFile 或 os.WriteFile 处理高频小文件写入，吞吐量很快会卡在系统调用和磁盘寻道上；真正能撑住高吞吐的，是组合缓冲、批处理和可控并发这三类设计模式。
用 bufio.Reader/Writer 替代裸系统调用
每次 file.Read 或 file.Write 都触发一次系统调用，对 SSD 可能还能扛，但对机械盘或网络存储，IOPS 会迅速见顶。bufio 的核心价值不是“快”，而是“少调用”。
- 读大文本时，优先用
bufio.NewScanner而非循环Read，默认缓冲区 4KB，可按需设为32 * 1024 - 写日志类场景，用
bufio.NewWriter，并在批量写完后显式调用Flush，避免缓冲区未落盘就进程退出 - 注意：缓冲区不是越大越好——64KB 以上对多数 SSD 场景收益递减，反而增加内存占用和延迟
批处理写入 + 合并小 IO
单次写 1KB 文件 1000 次，远不如合并成 1MB 一次写入。go-resiliency 的 batcher 很适合这个场景，但要注意它不负责文件系统层面的原子性。
- 超时设为
10–50ms：太短（100ms）让写入延迟不可控 - 批次函数里别做阻塞操作，例如直接调
os.WriteFile；应先聚合到内存 buffer，再统一Write到已打开的文件句柄 - 若需保证每条记录不丢，可在批处理前加
Prefilter校验格式，避免无效数据挤占批次空间
Worker Pool 控制并发写入数量
并发开 100 个 goroutine 写文件，不一定比 10 个快——尤其在机械盘或 NFS 上，随机写会因寻道时间爆炸式增长。
- IO 密集型写入（如日志落盘），worker 数建议设为
2–5 * runtime.NumCPU()，上限不超过 50 - 任务 channel 必须带缓冲，例如
make(chan *WriteTask, 100)，否则生产者（如 HTTP handler）会被阻塞 - 每个 worker 应复用
*os.File句柄，而不是每次新建；关闭前调用Sync()确保数据刷盘，但别每写一次都 Sync
避免 mmap 和递归遍历成为隐性瓶颈
很多人想用 mmap 加速大文件读取，但在 Go 中它并不比 bufio + io.Copy 稳定——尤其当文件被其他进程截断或 resize 时，容易 panic；而递归遍历目录树看似简单，实际会触发海量 stat 系统调用。
- 替代
filepath.Walk：用os.ReadDir（Go 1.16+）逐层读取，自己控制深度和过滤逻辑 - 避免在 hot path 中用
os.Stat判断文件是否存在，改用errors.IsNotExist捕获 open 失败更轻量 -
mmap仅在固定大小、只读、内存充足的大文件场景下有优势；日常日志或配置文件读取，纯属过度设计
真正难的不是选哪个模式，而是判断当前瓶颈在哪——是 CPU 在压缩、磁盘在寻道、还是 goroutine 在等锁。pprof 的 block 和 mutex profile 比 cpu profile 更容易暴露吞吐问题根源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
