os.ReadFile 不适合读取大文件，因其一次性加载全部内容到内存，易引发 OOM，且无缓冲控制、不支持流式处理、无法中断或偏移读取。
为什么 os.ReadFile 不适合读取大文件
os.ReadFile 会把整个文件一次性加载进内存，对于几百 MB 甚至 GB 级别的文件，极易触发 OOM（runtime: out of memory），且无缓冲控制、无法流式处理。它只适用于小配置文件或临时数据，不是“高效读取”的解法。
- 典型错误现象：
fatal error: runtime: out of memory或进程被系统 kill - 底层调用
bytes.Buffer.Grow预分配空间，但预估失败时会反复 realloc，加剧碎片和延迟 - 无进度反馈、无法中断、不支持偏移读取，调试和容错能力极弱
用 bufio.Scanner 按行读取文本大文件的边界问题
bufio.Scanner 默认最大令牌长度是 64KB（bufio.MaxScanTokenSize），遇到超长行（如单行 JSON、日志堆栈、CSV 中含大字段）会直接报错：scanner: token too long。这不是 bug，是设计限制。
-
解决方法：显式设置
Split并调大Buffer - 示例：
sc := bufio.NewScanner(f) sc.Buffer(make([]byte, 0, 64*1024), 10*1024*1024) // 初始 64KB，上限 10MB sc.Split(bufio.ScanLines)
- 注意：
sc.Buffer第二个参数是硬上限，超过仍 panic；若不确定最长行，改用bufio.Reader+ReadString更可控
真正可控的大文件流式读取：用 bufio.Reader 分块读取
这是最通用、最稳定的方式——不假设格式，不依赖行分隔，可精确控制每次读多少字节，适配二进制/文本/自定义协议。
- 核心操作是
r.Read(p []byte)，返回实际读到的字节数n和err -
io.EOF表示文件结束，不是错误，需单独判断 - 推荐块大小：256KB–1MB（
32 * 1024到1024 * 1024），太小增加系统调用开销，太大占用过多堆内存 - 示例关键片段：
buf := make([]byte, 512*1024) r := bufio.NewReader(f) for { n, err := r.Read(buf) if n > 0 { process(buf[:n]) // 处理有效数据 } if err == io.EOF { break } if err != nil { log.Fatal(err) // 或按需处理其他 err（如 timeout、interrupt） } }
需要随机访问或部分读取？用 os.File.ReadAt + sync.Pool
当你要跳过头部、只读某一段（比如解析 tar、zip、数据库快照），或并发读多个区域时，ReadAt 比 seek+read 更安全（无需考虑并发 seek 冲突）。
立即学习“go语言免费学习笔记（深入）”；
-
ReadAt是线程安全的，适合搭配sync.Pool复用缓冲区 - 避免为每次读分配新切片：
var bufPool = sync.Pool{ New: func() interface{} { return make([]byte, 0, 1024*1024) }, } buf := bufPool.Get().([]byte) defer bufPool.Put(buf) n, err := f.ReadAt(buf[:cap(buf)], offset) - 注意：
ReadAt不会自动更新文件偏移量，适合“只读不移动”场景；若需顺序读+跳转混合，仍建议用Seek+Read
真正难的不是“怎么读”，而是读的过程中如何不丢数据、不爆内存、不阻塞协程、还能优雅中断。缓冲区大小、错误分类、EOF 判断位置、池化对象生命周期——这些细节没对齐，再“高效”的方案也会在压测时崩掉。
