bufio性能优化关键在合理控制缓冲区大小并避免误用：Reader需防绕过缓存和底层混用，Writer须显式Flush防丢数据，Scanner有行长度限制且不支持回退。
直接用 os.File.Read 或 os.File.Write 做小量频繁读写，性能会明显低于预期——这不是磁盘慢，是系统调用开销和内核态/用户态切换拖了后腿。用 bufio 包不是“加个壳就变快”，关键在控制缓冲区大小、避免误用底层 io.Reader/io.Writer 接口导致的隐式 flush 或阻塞。
bufio.Reader 的缓冲行为与常见卡点
bufio.Reader 不会自动预读全部数据，只在缓冲区空且需要更多字节时才触发一次底层 Read 调用（默认 4KB）。这意味着：
- 调用
reader.ReadByte()读 1 字节，若缓冲区还有剩余，直接返回；否则触发一次系统调用填满缓冲区再取 - 用
reader.Read(p []byte)读大块数据时，如果len(p)> 缓冲区剩余容量，bufio会绕过缓冲区，直接委托给底层Read——此时没走缓存，等于白套 - 对网络连接（如
net.Conn）用bufio.NewReader后，别混用底层连接的Read：缓冲区可能已预读但未消费，造成数据错位
reader := bufio.NewReader(file) buf := make([]byte, 1024) n, _ := reader.Read(buf) // 如果 buf 太大或 reader 缓冲区已空，这里可能不走缓存 // 更稳妥：用 reader.Peek / reader.Discard 控制预读节奏
bufio.Writer 的 flush 时机与丢数据风险
bufio.Writer 的写入只有在缓冲区满、显式调用 Flush() 或 Close() 时才会真正落盘。漏掉 Flush() 是最常见丢数据原因。
- 写入量小于缓冲区（默认 4KB），又没
Flush()或Close()→ 数据卡在内存里，进程退出即丢失 - 用
writer.WriteString()后立刻os.File.Stat()查文件大小？结果仍是旧值——因为还没刷出去 - 多 goroutine 并发写同一个
bufio.Writer？未加锁会导致 panic 或数据覆盖，它不是并发安全的
w := bufio.NewWriter(file)
w.WriteString("hello")
// 忘记这行，"hello" 可能永远不会写入磁盘
w.Flush()
如何设置合理的缓冲区大小
默认 4KB 适合通用场景，但实际应按使用模式调整：
立即学习“go语言免费学习笔记（深入）”；
- 读日志文件（逐行处理）：增大到 64KB–1MB，减少
read(2)系统调用次数；但别超过单行最大长度，否则ReadString('\n')可能失败 - 写数据库导出 CSV：每行约 200B，批量写 1000 行 → 缓冲区设为 256KB 更稳
- 嵌入式或内存受限环境：可设为 512B，但要接受更高系统调用频率
- 注意：
bufio.NewReaderSize和bufio.NewWriterSize第二个参数必须 > 0，传 0 会 panic
// 安全的最小缓冲区设置 r := bufio.NewReaderSize(file, 512) w := bufio.NewWriterSize(file, 8192)
bufio.Scanner 不是万能替代品
很多人用 bufio.Scanner 替代 Reader 读行，但它有硬限制：
- 默认单行上限 64KB，超长行会报
scanner.ErrTooLong，需提前用Scanner.Buffer扩容 - 不支持
UnreadRune或任意位置回退，遇到需要“试探性读取+回退”的协议解析（如 HTTP header 解析）必须换回Reader - 底层仍用
Reader，但封装隐藏了缓冲区管理逻辑——调试时看不到实际读了多少字节
scanner := bufio.NewScanner(file) scanner.Buffer(make([]byte, 64*1024), 1<<20) // 扩容至 1MB
缓冲区不是越大越好，也不是越小越省；真正影响性能的是「缓冲区命中率」和「flush 频率」的平衡。别只盯着 NewReader 这一行代码，得看住你每次 Read 的 size、是否跨 goroutine 共享、以及有没有漏掉 Flush 或 Close。
