bufio.NewReader 比 os.ReadFile 快是因为它用固定缓冲区（默认4096字节）边读边处理，避免大文件OOM，减少系统调用次数；但不加速磁盘I/O，适合逐行处理大文件。
bufio.NewReader 为什么比 os.ReadFile 快
因为 os.ReadFile 是一次性把整个文件加载进内存，遇到几百 MB 的日志或数据文件会直接 OOM；而 bufio.NewReader 只维护一个固定大小的缓冲区（默认 4096 字节），边读边处理，内存占用稳定。它不提速磁盘 I/O，但能显著减少系统调用次数——每次 Read 调用实际可能从内核缓冲区拿多字节，避免频繁陷入内核。
- 适合逐行处理大文件（如日志分析、CSV 解析）
- 不适合随机访问或需要全文搜索的场景
- 缓冲区大小可调：
bufio.NewReaderSize(f, 64*1024)对 SSD 或高吞吐场景常设为 64KB
按行读取时必须检查 err == io.EOF
bufio.Scanner 默认行为是丢弃最后一行没换行符的内容（比如文件末尾缺 \n），且不报错；而 bufio.Reader.ReadString('\n') 在读到文件末尾但没遇到分隔符时会返回 "" 和 io.EOF。很多人只判断 err != nil 就跳出循环，结果漏掉最后一行。
- 正确写法：
line, err := r.ReadString('\n'); if err != nil && err != io.EOF { /* 处理真实错误 */ }; if line != "" { /* 处理本行 */ } -
bufio.Scanner更安全：它自动处理 EOF 和无换行末行，但最大单行限制默认 64KB（可通过ScanLines+MaxScanTokenSize调整） - 若需保留原始换行符，用
ReadString；若想自动 trim，Scanner.Text()更方便
bufio.Reader.Read 不保证填满缓冲区
调用 r.Read(buf) 返回的 n 可能小于 len(buf)，即使文件还没读完——这是正常行为，不代表错误。常见误用是假设每次都能读满，导致逻辑跳过部分数据。
- 必须用
n, err := r.Read(buf); if n == 0 && err == nil { continue }判断空读 - 真正结束只看
err == io.EOF，不是n == 0 - 批量读取推荐用
io.ReadFull(r, buf)（要求必须读满）或封装循环读取逻辑
文件句柄泄漏和 defer 的坑
很多人写 defer f.Close() 后直接传 f 给 bufio.NewReader，以为没问题。但若 bufio.Reader 持有文件指针，而后续代码 panic 或提前 return，defer 确实会关，可如果中间还开了其他 reader（比如多个 goroutine 并发读同一文件），就可能触发 “file already closed” 错误。
立即学习“go语言免费学习笔记（深入）”；
- 确保每个
os.File只被一个bufio.Reader使用 - 不要复用
bufio.Reader跨 goroutine —— 它不是并发安全的 - 若需并发读，要么用
sync.Pool管理bufio.Reader实例，要么每个 goroutine 自己os.Open+defer Close
实际优化效果取决于磁盘类型和访问模式：对 HDD，增大缓冲区 + 减少 seek 次数收益明显；对 NVMe，重点反而是减少锁竞争和 GC 压力——这时候别盲目堆大 buffer，先 profile runtime.ReadMemStats 和 pprof 的 allocs。
