bufio.Reader.Read可精确控制每次读取字节数，减少系统调用，适用于二进制或自定义格式大文件；需指定合适缓冲区大小（如1MB），显式处理io.EOF和io.ErrUnexpectedEOF，复用缓冲区并注意切片有效性。
用 bufio.Reader.Read 控制每次读取字节数
直接调用 file.Read(buf) 虽底层，但容易忽略错误判断和 EOF 边界；bufio.Reader 封装了缓冲逻辑，减少系统调用次数，同时保持对块大小的完全控制，是二进制或自定义格式大文件的首选。
- 初始化时指定缓冲区大小：
reader := bufio.NewReaderSize(file, 1024*1024)（如 1MB），避免默认 4KB 太小导致频繁 syscall - 每次调用
reader.Read(buf)最多读len(buf)字节，返回实际读取数n，必须用buf[:n]处理有效部分，不能直接用整个buf - 遇到
io.EOF表示结束，其他错误（如io.ErrUnexpectedEOF）需区分：它常出现在块末尾不完整时（比如协议头固定 16 字节，但只剩 5 字节可读），不能一概当失败中断 - 不要在循环里反复
make([]byte, size)，复用同一底层数组——要么预分配后传入，要么用sync.Pool管理缓冲区
scanner.Buffer() 不是给大文件扩容，而是防单行长爆内存
很多人以为 bufio.Scanner 的 Buffer 方法是用来“支持 GB 级文件”，其实它只管单行最大长度。文件再大，只要每行都短于缓冲上限，就不会 panic；但一行超长（比如日志里嵌了一整段 base64 图片），就会触发 scanner: token too long。
- 设缓冲上限要务实：
scanner.Buffer(make([]byte, 64*1024), 1024*1024)支持最长 1MB 的单行，比设math.MaxInt32安全得多 -
scanner.Text()返回的是内部缓冲区的切片视图，下一次Scan()就会覆盖——若你存了line到 map 或 slice 里，没做拷贝，最后所有值都变成最后一行 - 真要保留多行字符串，用
string(scanner.Bytes())或append([]byte{}, scanner.Bytes()...)显式复制 - 纯流式处理（统计、过滤、转发）完全不需要拷贝，直接用
scanner.Text()即可
并行读块时，ch := make(chan []byte, N) 的 N 必须显式限制
把读取和处理拆到不同 goroutine 看似能提速，但 channel 若不限缓冲，未消费的块会在内存中堆积，很快耗尽可用内存——尤其当处理函数含网络请求或 DB 写入等慢操作时。
- channel 缓冲大小建议 ≤ 3～5，例如
ch := make(chan []byte, 3)，表示最多缓存 3 块待处理数据 - 发送前必须深拷贝：
ch ，否则所有 goroutine 共享同一底层数组，内容互相污染 - worker 从 channel 取出后，处理完即可丢弃引用，GC 才能及时回收；别把它塞进全局 map 或长期存活结构体里
- 如果单块处理耗时稳定且
别碰 mmap 除非你清楚随机访问 + 零拷贝的代价
mmap 把文件映射成内存地址，读写像操作切片一样快，但它不是万能加速器：跨平台行为不一致（Windows 上需额外权限）、内存页管理不可控、且 Go 运行时 GC 不感知 mmap 区域，容易误判内存压力。
立即学习“go语言免费学习笔记（深入）”；
- 仅适合场景：文件极大（>10GB）、需频繁跳转读取（如数据库索引扫描）、且业务能精确控制访问范围
- Go 官方无
mmap支持，得用golang.org/x/exp/mmap（非稳定 API）或 syscall 直接调用，维护成本高 - 普通顺序读取、分块解析、上传、转换等任务，
bufio.Reader已足够高效，强行上 mmap 反而增加复杂度和风险 - 若真要用，记得
defer r.Close()，且避免对 mmap 区域做大量小粒度切片赋值（易触发隐式 copy）
真正卡住性能的往往不是读取本身，而是处理逻辑里悄悄累积的引用、未关闭的文件描述符、或者对缓冲区生命周期的误判。块大小设多少，取决于你的处理单元粒度；要不要并发，得看瓶颈在 IO 还是 CPU；而所有“省事”的封装，背后都有它默认假设的边界条件——看清这些，才能让大文件读取既稳又轻。
