Go语言如何提升大批量数据写入文件的操作速度

你的两个实现性能上不去，核心问题非常明确：

• 方案B的性能瓶颈是循环内逐次调用Sync()：该操作会强制将内核页缓存数据刷到物理磁盘，每次刷盘都对应高昂的磁盘IO开销，直接把批量顺序写入变成了逐次随机写入，性能差是必然结果。
• 方案A虽然用了带缓冲的IO，但默认配置和写法存在不少冗余开销，没有发挥出批量写入的性能优势，所以和方案B拉不开明显差距。

按收益从高到低排序：

• 移除循环内的Sync()调用
  操作系统会自动在后台将页缓存中的数据批量刷入磁盘，批量顺序刷盘的性能比逐次刷盘高2~3个数量级。除非你有极强的一致性要求（比如写入完成前进程崩溃也不能丢数据），否则完全不需要手动调用Sync()；即使有一致性要求，也只需要在所有数据全部写入完成后调用一次即可，绝对不要放在写入循环里。
• 调大bufio.Writer的缓冲区大小
  方案A用的是bufio.NewWriter默认的4KB缓冲区，写入大批量数据时缓冲区太小会导致频繁触发底层write系统调用，而系统调用的上下文切换开销很高。可以根据内存情况把缓冲区调整到256KB~4MB区间，大幅减少系统调用次数。初始化方式：

  // 初始化1MB大小的缓冲区，可根据实际场景调整
  w := bufio.NewWriterSize(f, 1024*1024)
  

• 消除循环内的冗余内存分配和函数调用开销
  方案A中每次循环调用fmt.Sprint(d + "\n")存在两个明显浪费：一是fmt.Sprint内部走反射逻辑判断值类型，开销远高于直接写入；二是每次都会生成新的临时字符串，产生大量短命对象给GC增加压力。
  如果d本身是字符串类型，直接调用w.WriteString(d)后再写入换行符即可，不需要经过fmt转换；如果是数值等其他类型，优先用strconv包的对应方法直接写入writer，避免生成中间临时字符串。
• 提前预分配文件空间
  如果能提前计算出待写入数据的总大小，打开文件后直接调用f.Truncate(totalSize)预分配对应大小的磁盘空间，可以避免写入过程中操作系统动态扩容文件、更新文件元数据的开销，同时减少磁盘碎片，对机械硬盘场景提升尤其明显。
• 超大数据量场景可使用mmap内存映射
  如果单文件写入量达到GB级别，可以用syscall.Mmap将文件直接映射到用户态内存，写入时直接操作内存即可，省掉用户态和内核态之间的内存拷贝开销，性能会比普通缓冲IO更高。但mmap的使用复杂度更高，需要手动处理映射长度、脏页同步等问题，适合固定的超大规模写入场景。

f, err := os.Create("file.txt")
if err != nil {
    log.Fatal(err)
}
defer f.Close()

// 已知总大小时打开，提前预分配空间，未知大小可跳过
// totalSize := 计算得到的文件总字节数
// if err = f.Truncate(totalSize); err != nil {
//     log.Fatal(err)
// }

// 初始化1MB缓冲区的writer
w := bufio.NewWriterSize(f, 1<<20)
for _, d := range data {
    // 按d的实际类型选择写入方式，这里以d为字符串举例
    _, _ = w.WriteString(d)
    _ = w.WriteByte('\n')
}
// 最后统一刷新缓冲区
if err = w.Flush(); err != nil {
    log.Fatal(err)
}
// 强一致性要求场景打开，所有写入完成后同步一次即可
// if err = f.Sync(); err != nil {
//     log.Fatal(err)
// }

正常优化后，写入性能基本可以打满磁盘的顺序写入带宽：机械硬盘场景可以达到100~200MB/s，消费级SATA SSD可以达到500MB/s左右，NVMe SSD可以达到几GB/s，远高于你当前两个实现的性能。

注意：写入过程中不要频繁调用会修改文件元数据的操作（比如重复chmod、chown），这类操作会强制触发磁盘同步，直接把顺序IO的性能打回随机IO水平。

内容的提问来源于stack exchange，提问作者shekwo