f.readlines() 会把整个文件所有行一次性加载进内存，生成一个巨大的 list 对象，这是 OOM 的直接原因。
为什么 readlines() 必然触发 MemoryError
它不是“读得慢”，而是设计上就拒绝流式处理：readlines() 内部先调用 read() 拿到全部字节，再按 \n 切分，最后为每一行创建独立的 str 对象，并把所有对象指针塞进一个新 list。哪怕文件是 2GB 文本，Python 字符串对象开销 + list 的指针数组，实际内存占用常达 3–4GB。
常见错误现象包括：
-
MemoryError抛出，进程退出 - 系统变卡，
ps aux显示 Python 进程 RSS 突增至数 GB - 在容器或低配云服务器上被 OOM Killer 直接杀掉（
dmesg | tail可查）
for line in f 为什么不会 OOM
文件对象 f 本身是迭代器，for line in f 底层调用 f.__next__()，每次只从内核缓冲区解析出一行（含换行符），构造一个 str，交给你的处理逻辑；上一行对象一旦失去引用，就立即被 GC 回收。内存占用始终稳定在「单行最大长度 + 少量缓冲」级别，通常几十 KB 到几 MB。
立即学习“Python免费学习笔记（深入）”；
注意几个关键点：
- 必须用
with open(...)或显式f.close()，否则文件句柄泄漏可能掩盖内存问题 - 如果某行本身超长（比如单行 500MB 的 base64），这一行仍会 OOM —— 这是数据格式问题，和读取方式无关
- 编码错误（如用
utf-8解码含二进制垃圾的 log）可能导致某行解码失败并卡住，看似“内存涨”，实为阻塞
什么时候不得不避开逐行读取
当文件没有换行符（如二进制 dump、自定义帧格式）、或需要跨行匹配正则（如多行日志堆栈）、或要随机跳转位置时，for line in f 失效，就得切块读：
用 f.read(chunk_size) 手动管理缓冲区，自己拼接未闭合的行。典型 chunk_size 是 8192 或 65536，太小（如 1024）会导致系统调用频繁、I/O 效率骤降；太大（如 100MB）又失去内存控制意义。
示例核心逻辑：
buffer = ""
while True:
chunk = f.read(8192)
if not chunk:
if buffer:
yield buffer
break
buffer += chunk
while "\n" in buffer:
line, buffer = buffer.split("\n", 1)
yield line + "\n"
真正容易被忽略的不是“怎么选方法”，而是：逐行读取只解决「行边界清晰」的文本；一旦数据结构越界，缓冲区管理的细节（比如换行符归属、BOM 处理、编码回退）立刻变成内存和逻辑双崩点。
