bufio通过缓冲区减少系统调用次数来提升I/O性能，每次读写优先操作内存缓冲区，默认4096字节为平衡点，可依场景调整大小；Writer需显式Flush，Scanner等方法依赖缓冲机制，但缓冲不能替代对数据模式与资源边界的合理评估。
bufio 能提升 I/O 性能，核心就一条：用内存换系统调用次数 —— 每次 Read 或 Write 不再直连内核，而是先跟缓冲区打交道。
缓冲区如何减少系统调用？
每次调用 conn.Read() 或 file.Read() 都会触发用户态 → 内核态切换（约 1–2μs），还要拷贝数据。而 bufio.Reader 的 Read() 方法内部逻辑是：
- 先检查自己缓冲区是否还有数据 → 有，直接拷贝返回（50ns 级别，纯内存操作）
- 缓冲区空了 → 才真正调用底层
Read()，一次性读取 4KB（默认大小）进缓冲区 - 后续多次小读取，都从这块内存里“分发”，不再碰系统调用
比如读 1000 行日志（每行 200 字节），不带缓冲可能触发 1000 次系统调用；用 bufio.NewReader() 后，往往只需 5–10 次批量读取。
为什么默认 4096 字节？这个值怎么调？
4096 是平衡点，不是银弹。它在大多数场景下兼顾内存占用与系统调用频率，但真实业务中常需调整：
立即学习“go语言免费学习笔记（深入）”；
- 网络服务处理小包（如 HTTP header、RPC 请求）→ 缓冲区过大会浪费内存且延迟略升，可试
bufio.NewReaderSize(conn, 2048) - 批量写入大日志或导出 CSV → 建议增大到
65536（64KB），显著降低write(2)次数 - 内存受限环境（嵌入式、Serverless）→ 可压到
1024，但要接受更高系统调用开销
注意：bufio.NewReaderSize() 和 bufio.NewWriterSize() 必须在初始化时指定，运行时无法修改。
不 Flush 就丢数据？Writer 的隐藏陷阱
bufio.Writer 的缓冲是“写入即缓存”，不显式刷出，数据就卡在内存里 —— 这不是 bug，是设计：
- 调用
w.Write()只是把数据塞进缓冲区，不保证落盘或发到对端 - 程序正常退出前必须调
w.Flush()，否则最后一段内容永远不出现 - 若写入中途 panic 或 os.Exit()，
defer w.Flush()也不会执行 → 推荐搭配defer func(){ _ = w.Flush() }()更稳妥 - 高并发下多个 goroutine 共享一个
bufio.Writer？不安全 —— 它没做并发保护，必须加锁或每个 goroutine 独占一个实例
Peek / ReadString / Scanner 这些方法背后都依赖缓冲
像 reader.ReadString('/n') 或 scanner.Scan() 看似简单，实则高度依赖缓冲机制：
-
ReadString()会在缓冲区里逐字节扫描，直到遇到'/n'；如果一行跨了两次底层读取，它会自动触发第二次填充 —— 你完全感知不到 -
Peek(1)是零拷贝预读：只看下一个字节不移动读位置，适合协议解析（如判断消息类型） -
Scanner底层就是封装了bufio.Reader，但默认缓冲区仍是 4KB；若扫描超长行（>4KB），会自动扩容，但频繁扩容有分配压力
所以别以为用了 Scanner 就万事大吉 —— 如果你的日志行平均 16KB，建议初始化时传自定义 bufio.NewReaderSize(file, 65536) 给 Scanner。
缓冲不是万能加速器，它把“系统调用开销”转化成了“内存占用 + 缓冲管理逻辑”。真正影响性能的，从来不是 bufio 本身，而是你有没有看清数据模式、调用节奏和资源边界。