直接 open()+readlines() 会爆内存,因为 readlines() 将整个文件一次性加载进内存,产生远超文件大小的字符串对象开销;应改用 for line in f: 或自定义带异常处理的生成器。

为什么直接 open() + readlines() 会爆内存
因为 readlines() 会把整个文件一次性加载进内存,哪怕只是想逐行处理。1GB 的日志文件,可能瞬间吃掉 2GB+ 内存——不是文件大小,是 Python 字符串对象的额外开销和换行符缓存导致的。
真正要的是“按需取一行”,不是“全拿进来再切”。生成器 yield 正是干这个的:函数返回一个迭代器,每次只产出一行,上一行对象可被垃圾回收。
- 别用
for line in f.readlines():—— 它已经把全部行存在列表里了 - 改用
for line in f:(底层就是基于迭代器,等价于手动 yield) - 如果需要预处理(比如跳过注释、拆字段),就封装成自定义生成器函数
怎么写一个安全的逐行生成器(带编码和异常处理)
文件编码不一致、中间出现坏字节、权限突然丢失……这些都会让裸 for line in f: 直接报错中断。生产环境必须兜底。
关键点:用 try/except 包住单行读取逻辑,跳过出问题的行,而不是整个流程崩掉;显式指定 encoding,避免平台默认编码差异(比如 Windows 的 cp1252 vs Linux 的 utf-8)。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本,属于3.14系列的第二个维护更新。该版本包含了18项修复,重点解决了多进程、数据类及正则表达式等模块的回归问题,并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式(移除GIL)正式获得官方支持,是Python发展的重要里程碑。
- 始终传
encoding='utf-8',除非你明确知道文件是gbk或latin-1 - 用
errors='ignore'或errors='replace'处理非法字节,别留空(默认是'strict') - 在生成器内部捕获
UnicodeDecodeError和IOError,yield前记录警告即可,不要 raise
def safe_line_reader(filepath):
with open(filepath, encoding='utf-8', errors='replace') as f:
for i, line in enumerate(f):
try:
yield line.rstrip('\n\r')
except (UnicodeDecodeError, OSError):
print(f"Warning: skip corrupted line {i} in {filepath}")
yield 生成器和 itertools.islice 搭配读取指定行范围
有时候不是从头读,而是想取第 10000–10100 行做抽样分析。用 islice 配合生成器,既不提前加载、也不手动计数,还避免自己写 while + readline 容易漏掉最后一行的 bug。
islice 是惰性的:它会跳过前面的行,但不会把它们加载进内存,只消耗迭代器——这正是生成器的优势所在。
- 别用
list(f)[start:end]—— 全部加载了,白写了生成器 - 用
itertools.islice(safe_line_reader(path), start, end) - 注意
islice返回的是迭代器,不能重复遍历;需要多次用就转成list(),但仅限小范围 - 起始索引从 0 开始,
islice(gen, 9999, 10100)才是第 10000–10100 行
什么时候 yield 反而更慢?小心磁盘 I/O 成瓶颈
生成器解决的是内存问题,不是速度问题。如果文件在机械硬盘上,且每行处理逻辑极轻(比如只统计长度),那么频繁的系统调用(每次 yield 对应一次 read() 底层调用)可能比批量读块(如 f.read(8192))更慢。
这时候应该权衡:是内存受限(服务器只有 512MB RAM),还是纯吞吐优先(离线分析,有 32GB 内存)?前者无条件用生成器;后者可考虑缓冲读取 + 字符串 splitlines()。
- SSD 上差异很小,不用纠结
- 网络文件系统(NFS/SMB)或远程对象存储(S3 via boto3)慎用纯行迭代,延迟高,建议分块下载本地再处理
- 若处理逻辑本身很重(比如每行都调用正则 + JSON 解析),I/O 差异基本被掩盖,放心用 yield
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










