缓冲区并非越大越好，4KB默认值多数场景已够用；设1MB易拖慢GC、增内存占用且对SSD吞吐提升甚微；应据数据块规律调整，如日志行均长5KB则设64KB以减少系统调用频次。
bufio.NewReaderSize 缓冲区设多大才合适
缓冲区不是越大越好，4KB 默认值在多数场景下已够用；设太大（比如 1MB）反而可能拖慢 GC、增加内存占用，且对 SSD 吞吐提升微乎其微。真正该调大的情况是：你处理的数据块有明显规律——比如日志行平均长度 5KB，那就设 bufio.NewReaderSize(f, 64*1024)（64KB），让一次系统调用尽可能填满缓冲，减少 read(2) 调用频次。
容易踩的坑：
- 盲目设成
1（1MB）却不验证实际吞吐，结果内存占用翻倍、延迟上升 - 用
ReadString('\n')处理超长行（如单行几百 MB），导致缓冲区不断扩容、OOM - 没意识到
Scanner默认单行上限 64KB，超限直接报bufio.Scanner: token too long
别用 os.ReadFile 处理海量文件
os.ReadFile 底层仍是循环 read(2)，对 GB 级文件可能触发上百次系统调用——这不是“读得慢”，是“调用太碎”。它适合配置文件、小模板等一次性加载场景，但绝不能用于日志归档、ETL 输入流。
正确做法是复用 *os.File + bufio.Reader，或更轻量的 bufio.Scanner（仅按行读时）：
立即学习“go语言免费学习笔记（深入）”；
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 统计行数？用
Scanner，它复用内部 buffer，比Reader.ReadString更省内存 - 需要随机跳转或解析二进制结构？改用
file.ReadAt()或mmap，绕过 bufio 的顺序预读逻辑 - 读完立刻丢弃内容？避免保留
buf引用，否则 GC 无法回收
io.CopyBuffer 是复制大文件的隐藏利器
io.Copy 默认用 32KB 缓冲，但无法定制；而 io.CopyBuffer(dst, src, buf) 允许你传入预分配的 []byte，既避免反复 make 带来的 GC 压力，又能匹配硬件页大小（如 64KB）提升 DMA 效率。
实操要点：
- 缓冲切片必须预先分配，且生命周期覆盖整个
CopyBuffer调用 -
buf长度不能为 0，否则退化为io.Copy行为 - 对 NVMe 盘复制 10GB 文件，用
make([]byte, 64*1024)比默认缓冲减少约 15% 系统调用次数 - 别在循环里每次都
make新切片——用sync.Pool复用
并发读不是万能解药，磁盘寻道会反噬性能
SSD 上并发读多个独立文件（如日志分片）可能提速，但对单个大文件开多个 goroutine 去读不同 offset，反而加剧寻道、降低吞吐。本质是磁盘 I/O 不是纯带宽问题，更是调度与队列问题。
真正值得并发的场景只有两类：
- 多个物理文件（如
/logs/2026-06-01/*.log） - 文件已天然分块（如对象存储的分段上传结果、HDFS block）
其他情况优先优化单路读取：调大缓冲、复用切片、用 mmap 替代拷贝——这些比堆 goroutine 更可靠。尤其要注意 mmap 在 Windows 上支持较弱，且写入需手动同步回盘。
