默认 bufio.Scanner 读大文件时因整行加载内存易 OOM，遇超长行会报 bufio.ErrTooLong；应调用 scanner.Buffer() 显式限制缓冲区，如 scanner.Buffer(make([]byte, 64*1024), 1<<20)。
Scanner 读大文件时内存暴增甚至 OOM
默认的 bufio.Scanner 会把整行内容加载进内存，遇到超长行（比如日志中混入 base64 或 JSON blob）或超大文件（几十 GB），scanner.Scan() 很快触发 scanner.Err() == bufio.ErrTooLong，甚至直接 OOM。这不是 bug，是设计使然——它优先保证单行完整性，不控制内存上限。
实操建议：
- 务必调用
scanner.Buffer()显式限制缓冲区大小，例如scanner.Buffer(make([]byte, 64*1024), 1 表示初始 64KB、上限 1MB - 避免用
scanner.Text()处理不可信输入；若需保留原始行末符，改用scanner.Bytes()+ 手动判断换行 - 对纯文本逐行处理且行宽可控（如 CSV、Nginx 日志），
Scanner仍是最简方案
用 bufio.Reader + ReadSlice 逐块读取更可控
当需要跳过前 N 行、提取某段二进制块、或按自定义分隔符（非 \n/\r\n）切分时，bufio.Reader 比 Scanner 更底层、更灵活。它不预分配大缓冲，也不自动跳过空白，一切由你决定。
常见错误：直接用 reader.ReadString('\n') 仍可能因单行过长 panic，应改用 ReadSlice 配合错误判断：
立即学习“go语言免费学习笔记（深入）”；
reader := bufio.NewReader(file)
for {
line, err := reader.ReadSlice('\n')
if err != nil {
if err == io.EOF || err == io.ErrUnexpectedEOF {
// 处理最后一行无换行符的情况
if len(line) > 0 {
process(line)
}
break
}
log.Fatal(err)
}
process(line)
}
注意：ReadSlice 返回的是底层缓冲区的切片，若需长期持有，必须 append([]byte{}, line...) 拷贝。
按固定块大小读取（如 4KB）适合二进制或流式解析
对视频片段、打包文件、或自定义协议载荷，按字节块读取比按行更自然。此时不应依赖任何行概念，直接用 io.ReadFull 或循环 reader.Read()。
关键点：
-
reader.Read(buf)不保证填满buf，返回实际读取字节数n，必须检查n == 0 && err == nil（空读）或err == io.EOF - 若需严格每次读取固定大小（如加密解密块），用
io.ReadFull(reader, buf)，它会在不足时返回io.ErrUnexpectedEOF - 缓冲区复用很重要：在循环外声明
buf := make([]byte, 4096)，避免高频堆分配
os.OpenFile + syscall.Read 性能临界点在哪
当文件大于 10GB 且吞吐要求极高（如日志归档管道），标准 bufio 层可能引入额外拷贝。此时可绕过 bufio，用 os.File.Read() 直接对接系统调用，但代价是失去缓冲和行切分能力。
适用场景有限：
- 只做顺序扫描、无需解析结构（如计算 checksum）
- 已知文件格式为定长记录，可用
binary.Read()配合file.ReadAt() - 配合
mmap（通过golang.org/x/sys/unix.Mmap）实现零拷贝访问，但 Windows 兼容性差、GC 不感知内存映射
真正卡性能的往往不是 Go 的 I/O 层，而是磁盘随机寻址、syscall 频率、或后续业务逻辑（如正则匹配、JSON 解析）。先 profile，再决定是否弃用 bufio。
大文件处理最易被忽略的，是忘记关闭文件句柄、未处理部分读取后的偏移错位、以及把 scanner.Text() 结果直接塞进 map 做 key —— 那个字符串背后可能还连着几 MB 的底层数组。
