go高并发本地文件i/o瓶颈主因是小块频繁系统调用和内存乱分配；应使用bufio缓存、sync.pool复用缓冲区、流式分块读写、合理控制并发度并预分配空间。
Go 里高并发本地文件 I/O 的瓶颈，基本不是硬盘慢，而是你让成百上千个 goroutine 同时调 os.File.Read 或 os.File.Write，每个都触发一次系统调用——syscall 开销叠加起来，比磁盘本身还拖累性能。
为什么 bufio 不起作用？检查 Flush 和复用
常见现象：加了 bufio.Writer 但写入耗时没降，甚至更卡。大概率是忘了调 Flush()，数据全堆在内存里，最后关文件时才集中刷盘，掩盖了缓冲效果；或者在循环里反复 new bufio.Writer，每次 new 都分配新缓冲区，GC 压力翻倍。
- 写入后必须显式调
w.Flush()，不确定时机就加defer w.Flush() - 别在 goroutine 内部 new
*bufio.Writer，要么复用一个实例（单写场景），要么从sync.Pool拿 -
bufio.Writer不是并发安全的，多个 goroutine 写同一实例会丢数据或 panic - 缓冲区大小要匹配场景：
64 * 1024适合日志追加，1024 * 1024（1MB）适合顺序写大文件
大文件别用 os.ReadFile，改用流式分块 + io.CopyBuffer
os.ReadFile 会把整个文件 load 到内存，1GB 文件直接 OOM；它本质是 io.ReadAll(io.Reader)，没有流控能力，也不支持中断或进度反馈。
- 用
os.Open打开文件，再套bufio.NewReader或直接传给io.CopyBuffer(dst, src, buf) - 手动分块读时，
buf := make([]byte, 64*1024)是较稳的选择，接近页大小且避免频繁分配 - 目标文件提前
output.Truncate(size)预分配空间，减少元数据更新和碎片 - 若需原子写（防中断损坏），先写临时文件，再
os.Rename，注意 NFS 不保证原子性
并发读写文件时，并非越多 goroutine 越快
硬盘 I/O 是物理瓶颈，尤其 HDD 寻道慢、SSD 控制器有队列深度限制。盲目开 100 个 goroutine 读同一个文件，反而导致 I/O 请求乱序、调度开销上升、甚至性能下降。
- 单文件读写，用 1–2 个 goroutine 就够；真正该并发的是「处理」环节，比如读一块 → 丢进 channel → 多个 worker 解析/压缩/加密
- 多文件并发时，用信号量（如带缓冲的
chan struct{}）或semaphore.NewWeighted控制总数，避免打开过多文件句柄或触发 ulimit - HDD 上并发度建议 2–4 路，SSD 可试 8–16 路，超过后吞吐不增反降
- 多个 goroutine 写同一文件？必须加
syscall.Flock文件锁，或统一走一个 writer goroutine + channel 中转
高频小写场景下，sync.Pool 缓冲区复用很关键
HTTP 服务每秒上千请求，每个都 make([]byte, 4096)，GC 会疯狂扫描这些短期对象；而 sync.Pool 复用定长切片，能省 30%+ GC 压力。
- 只池化高频、无状态、定长的
[]byte或bytes.Buffer，别池化结构体指针等大对象 - 归还前务必清空敏感内容：
buf = buf[:0]，否则可能跨请求泄露数据 - 示例池定义：
var bufferPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 64*1024) }} - 使用时：
buf := bufferPool.Get().([]byte); defer bufferPool.Put(buf[:0])
最易被忽略的一点：文件句柄复用。频繁 os.Open/os.Close 不仅触发 syscall，还可能 hit ulimit；长期运行的服务应缓存 *os.File 实例，按需 Seek(0, 0) 重置位置，而非反复开关。
