bufio.NewReader对小文件集合几乎没用，因其仅优化单文件内多次读的系统调用合并，而小文件场景瓶颈在于高频open/close、inode查找与页缓存预热；为每个小文件新建Reader还增加4KB内存开销和GC压力。
直接用 os.ReadFile 读大量小文件（比如日志切片、配置片段、CSV 行文件），性能差不是因为 Go 慢，而是每调一次都触发一次系统调用 + 一次内存分配；用 bufio.Reader 单次封装不能解决问题——它只对「单个文件内多次小读」有效，而小文件场景的瓶颈在「打开 + 关闭 + 系统调用频次」本身。
为什么 bufio.NewReader 对小文件集合几乎没用
bufio.NewReader 的价值在于把多次 Read 合并成一次系统调用，但如果你是循环打开 1000 个 2KB 的文件，每个只读一次（比如 reader.ReadString('\n')），那它只是在每个文件里多套了一层缓冲区，反而增加内存开销和初始化成本。真实瓶颈是 open/close 系统调用、inode 查找、页缓存预热，不是读取粒度。
- 默认 4KB 缓冲区对单次读 2KB 文件毫无收益，还多一次
copy - 每个
bufio.Reader实例至少占用 4KB 内存，1000 个就是 4MB 堆内存，易逃逸 - 频繁创建/销毁
bufio.Reader会抬高 GC 压力，尤其在短生命周期 goroutine 中
真正有效的优化：复用 os.File + sync.Pool 缓冲区
小文件读取快的关键不是“加缓冲”，而是“少开闭、少分配”。你应该让底层 *os.File 复用（比如用 os.OpenFile 配合 O_RDONLY | O_CLOEXEC），再把 bufio.Reader 的缓冲区从 sync.Pool 拿，用完归还。
- 避免为每个文件 new 一个
bufio.Reader，改用bufio.NewReaderSize(file, pool.Get().([]byte)) - 池中缓冲区大小设为常见文件最大尺寸 + 128 字节（如多数小文件 ≤4KB，则用
make([]byte, 0, 4192)） - 读完立刻
pool.Put(buf)，别等 GC；reader实例可直接丢弃，不需 Close - 若文件路径固定且数量可控（如
/var/log/app/*.log），先用filepath.Glob批量获取，再并发读，避免stat串行阻塞
按行读小文本文件时，scanner.Buffer() 必须显式调大
你可能用 bufio.Scanner 逐个读小文件，但默认 64KB 行长限制仍会误杀：某些小文件第一行就含 base64 或 JSON 字段，超长即报 scanner: token too long 并静默失败（Scan() 返回 false，但你不查 Err() 就以为读完了）。
- 每次新建 scanner 后立刻调
scanner.Buffer(make([]byte, 4096), 1（支持最长 1MB 行） - 别用
math.MaxInt32：万一某文件缺换行符，会尝试分配数 GB 内存，直接 OOM - 若需长期保存
scanner.Text()结果，必须用string(scanner.Bytes())显式拷贝，否则下一行覆盖缓冲区 - 纯过滤或统计类逻辑（如计数空行），可直接用
scanner.Bytes()，零字符串分配
比 bufio 更快的替代方案：io.ReadFull + 固定切片
当所有小文件大小高度一致（如固定 1KB 的 protobuf 序列化块、加密密钥片段），绕过 bufio 反而更快：io.ReadFull 直接读到指定长度切片，无缓冲区管理、无分隔符扫描、无状态维护。
- 提前
make([]byte, 1024)作为缓冲，传给io.ReadFull(file, buf) - 失败时检查是否为
io.ErrUnexpectedEOF（文件实际比预期短），而非泛化错误 - 配合
sync.Pool复用该切片，避免每次分配 - 注意：此法不适用于变长内容，也不处理换行或分隔符，仅适合结构完全已知的二进制小块
真正卡住性能的往往不是读取逻辑本身，而是打开文件的系统调用频次和缓冲区生命周期管理。不要看到“小文件”就条件反射套 bufio，先确认你的读模式：是一次读完一个文件，还是在一个文件里反复读小块？前者重点压 open 和复用，后者才轮到 bufio 发挥作用。
