Golang中直接文件读写效率低下，因频繁系统调用引发高昂上下文切换开销；bufio通过内存缓冲区聚合I/O操作，减少系统调用次数，显著提升性能。
Golang中，
bufio包通过引入一个缓冲区层，显著提高了文件读写效率，它减少了程序与底层操作系统之间进行系统调用的频率，将多次小规模的I/O操作聚合成少数几次大规模操作，从而降低了上下文切换的开销和磁盘I/O的等待时间。
Golang在处理文件I/O时，如果直接使用
os.File进行逐字节或小块数据的读写，会频繁触发系统调用。每次系统调用都涉及用户态到内核态的上下文切换，这个过程是相当耗费资源的。想象一下，你不是一次性把一桶水倒进杯子，而是用滴管一滴一滴地滴，效率自然低下。
bufio的核心思想就是建立一个内存缓冲区，将数据先写入这个缓冲区，待缓冲区满或达到特定条件时，再一次性地写入磁盘；读取时也类似，先从磁盘读取一大块数据到缓冲区，后续的读取操作就直接从内存中获取，直到缓冲区为空再进行下一次磁盘读取。
例如，一个简单的文本文件写入操作，使用
bufio可以这样实现：
package main
import (
"bufio"
"fmt"
"os"
)
func main() {
filePath := "output.txt"
file, err := os.OpenFile(filePath, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0644)
if err != nil {
fmt.Println("Error opening file:", err)
return
}
defer file.Close()
// 使用 bufio.NewWriter 包装 os.File
writer := bufio.NewWriter(file)
for i := 0; i < 10000; i++ {
_, err := writer.WriteString(fmt.Sprintf("Line %d: This is a test line.\n", i))
if err != nil {
fmt.Println("Error writing string:", err)
return
}
}
// 确保所有缓冲区中的数据都写入到底层文件
err = writer.Flush()
if err != nil {
fmt.Println("Error flushing writer:", err)
return
}
fmt.Println("Data written to", filePath)
// 读文件示例
readFile, err := os.Open(filePath)
if err != nil {
fmt.Println("Error opening file for reading:", err)
return
}
defer readFile.Close()
reader := bufio.NewReader(readFile)
lineCount := 0
for {
line, _, err := reader.ReadLine() // ReadLine 是一个方便的读取一行的方法
if err != nil {
if err == os.EOF {
break
}
fmt.Println("Error reading line:", err)
return
}
// fmt.Println(string(line)) // 如果文件很大，不建议打印所有行
lineCount++
}
fmt.Printf("Read %d lines from %s\n", lineCount, filePath)
}Golang中为什么直接的文件读写效率低下？
说实话，我个人觉得很多人在初学Golang文件操作时，往往会忽略一个核心问题：系统调用的开销。当你直接用
os.File的
Read或
Write方法处理少量数据时，例如每次只读写几个字节，每一次操作都会导致程序从用户态切换到内核态，让操作系统介入。这个上下文切换并不是免费的，它需要CPU保存当前进程的状态，加载内核的状态，执行I/O操作，然后再切换回来。这就像你每次要从冰箱里拿一小块奶酪，不是一次性拿出来，而是每次都打开冰箱门、拿一小块、关门，然后再重复这个过程。冰箱门开关的动作（系统调用）本身就比拿奶酪（实际数据传输）更耗时。
立即学习“go语言免费学习笔记（深入）”；
尤其是在处理大量小数据块的场景下，这种开销会被无限放大。比如，你要读取一个几GB的日志文件，如果每次只读取一个字符，那么将会有几十亿次的系统调用，这显然是不可接受的。即使是现代的SSD硬盘，虽然随机I/O性能已经非常出色，但频繁的系统调用依然会成为性能瓶颈，而不是硬盘本身的读写速度。所以，理解并避免这种“滴水式”的I/O操作，是优化Golang文件读写效率的关键第一步。
bufio.Reader 和 bufio.Writer 的核心工作原理是什么？
bufio包的核心在于它的内部缓冲区。我们可以把这个缓冲区想象成一个中转站。
对于
bufio.Reader，它的工作原理是“预读”。当你需要从文件中读取数据时，
bufio.Reader不会每次都直接去访问底层文件。相反，当它的内部缓冲区为空时，它会一次性地从底层
io.Reader（比如
os.File）中读取一大块数据（默认大小是4KB，但你可以通过
bufio.NewReaderSize自定义），然后将这些数据填充到自己的缓冲区里。之后，你的程序对数据的读取请求，比如
ReadByte()、
ReadString()或者
ReadLine()，都会优先从这个内存缓冲区中获取。只有当缓冲区的数据全部被读取完毕后，
bufio.Reader才会再次进行一次大的系统调用，从文件中读取下一块数据来填充缓冲区。这样一来，原本可能成千上万次的小规模文件读取系统调用，就被
bufio聚合成了少数几次大规模的读取操作，大大减少了系统调用的次数。
bufio.Writer的工作原理则恰好相反，它是“延迟写入”或者说“批量写入”。当你通过
bufio.Writer写入数据时，数据并不会立即被写入到底层
io.Writer（例如
os.File）。它会先被写入到
bufio.Writer的内部缓冲区中。只有当这个缓冲区被写满、你显式地调用了
Flush()方法，或者
Writer被关闭时，缓冲区中的所有数据才会被一次性地写入到底层文件。这同样有效地将多次小的写入操作合并成了一次大的写入操作，显著降低了系统调用的频率。这对于像日志记录这样频繁产生小段数据的场景尤其有用，避免了每次打印一行日志都触发一次磁盘写入。在我看来，
Flush()方法是
bufio.Writer最重要的一个操作，因为如果你忘记调用它，那么缓冲区中的数据可能永远不会被写入到文件中，导致数据丢失。
在哪些场景下使用bufio能带来显著的性能提升？
在我多年的开发经验中，
bufio几乎是处理文件或网络I/O的“万金油”，尤其在以下几种场景中，它的性能提升是立竿见影的：
处理大型文本文件： 无论是读取日志文件、CSV文件，还是解析配置文件，只要文件内容较大且需要逐行、逐字或逐块处理，
bufio.Reader
都能发挥巨大作用。bufio.Scanner
在内部就使用了bufio.Reader
，它非常适合高效地迭代处理文本文件的每一行。没有bufio
，你可能需要写很多额外的逻辑来手动管理缓冲区。频繁的小规模写入操作： 这是
bufio.Writer
的典型应用场景。比如，你的程序需要持续生成大量的日志信息，或者需要将计算结果分批次写入一个报告文件。如果每次fmt.Fprintf
或file.Write
都直接写入磁盘，那性能会非常糟糕。使用bufio.Writer
，这些零散的写入会先聚合在内存中，然后批量写入，大大减少了磁盘I/O的次数，提高了程序的响应速度。网络通信： 尽管标题是文件I/O，但值得一提的是，
bufio
在网络编程中也同样重要。当你通过TCP连接发送或接收数据时，尤其是需要处理协议中的消息帧或流式数据时，bufio.Reader
和bufio.Writer
可以有效地减少socket
系统调用的次数，提高网络吞吐量和降低延迟。我经常在构建高性能网络服务时，用它来封装net.Conn
。文件复制或移动： 当你需要复制一个大文件时，直接使用
io.Copy
（它在内部也可能利用了缓冲区）或者手动读写时，如果读写缓冲区设置得当，bufio
可以确保数据以较大的块进行传输，而不是频繁地小块读写，从而加速整个复制过程。
当然，也有一些情况下
bufio的优势不那么明显，比如处理非常小的文件（几KB甚至更小），这些文件可能一次性就能全部读入内存，此时
bufio带来的额外抽象层和内存开销可能抵消掉其带来的微小性能提升。但总体而言，在绝大多数需要与外部存储或网络进行交互的场景中，考虑使用
bufio都是一个明智的选择。
