Golang大文件逐行读取方法解析

Go中逐行读取大文件看似简单，实则暗藏缓冲区溢出、内存泄漏和文件句柄泄露三大陷阱：默认64KB缓冲区极易因超长行触发“token too long”错误，需按需谨慎扩容至1–2MB而非盲目设为最大值；Scanner返回的字符串和字节切片复用底层缓冲区，若需保存多行必须深拷贝，否则所有引用将被覆盖为最后一行；而文件句柄和内部缓冲区若未及时关闭与重置，会在长生命周期场景中迅速耗尽系统资源——真正决定成败的，不是“如何读”，而是“读完立刻释放什么”。

Scanner默认缓冲区太小导致大文件读取失败

Go 的 bufio.Scanner 默认缓冲区只有 64KB，遇到超长行（比如日志中带大段 base64、JSON 或 minified HTML）会直接报 scanner: token too long 错误，不是文件太大，而是某一行太长撑爆了缓冲区。

实操建议：

• 用 scanner.Buffer 主动扩大缓冲区，例如支持最长 1MB 的行：

  scanner := bufio.NewScanner(file)
  scanner.Buffer(make([]byte, 64*1024), 1024*1024)

• 别无脑设成 math.MaxInt32 —— 这会让 Scanner 尝试分配数 GB 内存，一旦遇到畸形输入（如缺失换行的超大块），程序直接 OOM
• 如果业务确定不会出现超长行，但文件本身几十 GB，缓冲区扩到 1–2MB 通常够用，兼顾安全与性能

ScanLines比ReadString('\n')更省内存但不可逆

Scanner.Scan() 底层调用的是 ScanLines 分割函数，它复用内部缓冲区，每次只拷贝换行符前的字节；而 bufio.Reader.ReadString('\n') 每次都 new 一个新字符串，GC 压力明显更高。

但注意：Scanner.Text() 返回的字符串底层指向 Scanner 自己的缓冲区，下一次 Scan() 就会覆盖——如果你把 scanner.Text() 结果塞进切片或 map 却没深拷贝，最后全变成最后一行的内容。

实操建议：

• 需要保留多行内容时，显式拷贝：

  line := strings.TrimSpace(scanner.Text())
  lines = append(lines, line) // strings.TrimSpace 已触发拷贝

• 纯流式处理（如解析、过滤、计数）直接用 scanner.Text() 安全，不存引用
• 若需原始字节（避免 UTF-8 解码开销），改用 scanner.Bytes()，同样要注意复用问题

按行读取时 bufio.Reader.ReadBytes('\n') 更可控

当 Scanner 的自动缓冲管理让你不放心（比如要精确控制内存上限、或需处理不以 \n 结尾的末行），bufio.Reader 的 ReadBytes 或 ReadLine 是更底层、更透明的选择。

ReadBytes 会包含换行符，ReadLine 不包含但可能返回部分数据（遇到缓冲区满且无换行时），需自行拼接 —— 大多数场景 ReadBytes 更直觉。

实操建议：

• 初始化 reader 时也记得设缓冲区：

  reader := bufio.NewReaderSize(file, 1024*1024)

• ReadBytes('\n') 返回 []byte，如果后续要 string 操作，用 string(bytes) 而非 string(bytes[:])（后者和 Scanner 一样危险）
• 文件末尾无换行符时，ReadBytes 会返回剩余内容 + io.EOF，需检查 err == io.EOF || err == nil 来收尾

逐行处理大文件必须关闭文件并及时释放引用

很多人只记得 defer file.Close()，却忽略：只要 scanner 或 reader 还活着，底层 *os.File 就无法被 GC 回收，尤其在长生命周期对象（如 HTTP handler、全局 worker）里反复打开大文件，fd 泄漏比内存泄漏来得更快。

更隐蔽的问题是：把 scanner 存在 struct 字段里，又没清空其内部 buf 字段，会导致大缓冲区长期驻留堆上。

实操建议：

• 用完立即 file.Close()，不要依赖 defer（defer 在函数退出才执行，而函数可能很久才退）
• 如果必须复用 scanner，每次用完手动清空：

  scanner = bufio.NewScanner(file) // 重建更安全
  // 或重置缓冲区：
  scanner.Buffer(make([]byte, 0, 64*1024), 1024*1024)

• 监控 fd 数量：lsof -p $(pidof yourapp)，发现持续增长就是没关干净

实际跑通的关键不在“怎么读”，而在“读完立刻扔掉什么”——缓冲区大小、字符串引用、文件句柄，三者漏掉任何一个，大文件就从功能需求变成运维事故。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Golang大文件逐行读取方法解析》文章吧，也可关注golang学习网公众号了解相关技术文章。