Python 读取大文件内存飙升复盘：从 read() 一次读入到分块迭代修复

线上任务偶尔会因为一行看起来很普通的 read() 把内存打满。问题不一定出在 Python 语言本身，而是文件处理方式没有和数据规模匹配：小文件时代没问题，大文件一来就变成事故。

这篇文章按一次故障复盘的方式，把“Python 读取大文件内存飙升”拆开看：影响面是什么，时间线里哪些现象最关键，触发条件是什么，根因为什么是一次性读入，最后如何改成分块迭代并建立防复发检查。

影响面：导入任务卡住并拖高内存

问题出现在一个 Python 后台导入任务里。用户上传数据文件后，任务会读取文件内容，做简单清洗，再写入后续处理队列。小文件一直正常，直到某次上传了一个接近 2GB 的日志文件。

可见影响有三个：

• 导入任务长时间没有完成。
• 机器内存快速升高，其他任务开始变慢。
• 进程最终被系统终止，用户只能看到导入失败。

这类问题的危险点在于：它不像语法错误那样立刻暴露，而是在文件规模增长后才出现。

时间线：从上传成功到任务被杀掉

先把故障过程按时间线还原，避免一开始就跳到代码结论：

• 10:02 用户上传大文件，上传接口返回成功。
• 10:03 后台导入任务开始读取文件。
• 10:04 内存曲线快速升高，CPU 也出现明显抖动。
• 10:05 任务日志停止刷新，队列积压开始增加。
• 10:06 进程被系统终止，本次导入失败。

这条时间线提示我们：问题发生在“读取文件”和“进入清洗逻辑”之间，重点应该先查文件读取方式。

触发条件：文件体积从几十 MB 变成数 GB

复查历史任务后，发现之前大多数文件只有几十 MB，最大也不到 200MB。出问题的文件接近 2GB，刚好把原来隐藏的内存风险放大。

一个典型的风险写法如下：

from pathlib import Path

def import_log_file(path: str) -> int:
    text = Path(path).read_text(encoding="utf-8")
    rows = text.splitlines()

    total = 0
    for row in rows:
        if row.strip():
            total += 1
    return total

这段代码在小文件上很好懂：先读出全部文本，再按行拆分。但在大文件上，它会同时持有整份文本和拆分后的行列表，内存占用会明显高于文件本身体积。

根因：read() 把整份文件搬进内存

根因不是“Python 不能处理大文件”，而是代码把文件当成小字符串处理。常见问题有三类：

• read() 或 read_text() 一次性读取整份文件。
• splitlines() 再复制出一份行列表。
• 清洗逻辑把中间结果继续放进列表，导致内存层层叠加。

可以用一个简单示意理解旧链路：文件先进入内存成为大字符串，再拆成大列表，最后才开始逐行处理。文件越大，中间对象越多，峰值内存越不可控。

修复动作：改成分块迭代和逐段处理

修复思路是把“整份文件先读完”改成“按行或按块逐段处理”。如果业务逻辑按行清洗，直接迭代文件对象通常就够用：

from pathlib import Path

def import_log_file(path: str) -> int:
    total = 0
    with Path(path).open("r", encoding="utf-8") as file:
        for row in file:
            if row.strip():
                total += 1
    return total

如果处理的是二进制文件，或者需要固定大小分段，可以使用 read(size)：

from pathlib import Path

def count_bytes(path: str, chunk_size: int = 1024 * 1024) -> int:
    total = 0
    with Path(path).open("rb") as file:
        while True:
            chunk = file.read(chunk_size)
            if not chunk:
                break
            total += len(chunk)
    return total

修复后的链路应该变成这样：

这次改动的关键不是把某个函数换成另一个函数，而是把处理模型从“先全量加载”改成“边读边处理”。这样峰值内存主要由单行长度或块大小决定，而不是由整个文件体积决定。

防复发：给文件处理链路加上边界

事故修好以后，还要把边界补上，否则下一类大文件仍然可能触发类似问题。

• 入口限制：上传入口明确最大文件体积，超过限制给出清晰提示。
• 读取规则：评审文件处理代码时，重点检查是否有全量读取。
• 任务监控：为导入任务加内存、耗时和失败计数。
• 异常样本：保留一个大文件测试样本，发布前做回归运行。
• 中间结果：避免把所有清洗结果攒在列表里，能逐批写出就逐批写出。

总结一下：Python 处理大文件的核心原则是避免一次性把全部内容搬进内存。先还原影响和时间线，再定位触发条件，最后把读取模型改成迭代式处理，这样才能把问题从“偶发事故”变成“可控边界”。