open().readlines() 会 OOM 是因为它一次性将整个文件加载进内存生成列表；安全做法是用 for line in open() 或 with open() as f: for line in f，利用文件迭代器按需读取。
为什么直接 open().readlines() 会 OOM
因为 readlines() 会一次性把整个文件加载进内存，生成一个包含所有行的 list。哪怕文件只有 5GB，只要某台机器内存不足 8GB，就大概率触发 MemoryError。这不是 Python 的 bug，是设计使然——它本就为“全量加载”而生。
真正安全的做法是让 Python 按需吐出每一行，不缓存、不预读、不攒列表。这正是文件对象本身作为迭代器的默认行为。
-
for line in open("huge.log"):是安全的，底层调用__next__()，每次只 hold 一行字符串 -
open("huge.log").readlines()是危险的，尤其在处理 GB 级日志或 CSV 时 - 注意：即使用了迭代器，如果某一行本身超长（比如单行 200MB 的 base64），依然可能 OOM —— 这属于数据格式问题，和读取方式无关
如何用 with + 迭代器保证资源安全
裸写 open() 有风险：异常中途退出时文件句柄不释放。必须搭配 with 语句，同时保留迭代器语义。
正确写法就是最朴素的组合：
立即学习“Python免费学习笔记（深入）”；
with open("access.log", "r", encoding="utf-8") as f:
for line in f: # ✅ f 是迭代器，line 是 str（含换行符）
process(line)
- 不要写
for line in f.readlines():—— 又绕回了全量加载 - 编码错误（如
UnicodeDecodeError）常因文件含 BOM 或混用编码，建议显式指定encoding="utf-8-sig"自动剥离 BOM - 若需跳过空行或注释行，直接在循环内
if not line.strip() or line.startswith("#"): continue，别提前filter()—— 那会构建新迭代器但无实际收益
需要按块读取（非按行）时怎么控制内存峰值
有些场景不适合按行（比如二进制 chunk、固定长度记录、或行结构不规范），就得手动控制缓冲区大小。
用 iter() + functools.partial 构造分块迭代器，比 while + f.read(n) 更 Pythonic：
from functools import partial
<p>with open("data.bin", "rb") as f:
for chunk in iter(partial(f.read, 8192), b""):
process(chunk) # 每次最多 8KB，内存占用可控
-
partial(f.read, 8192)创建一个“无参函数”，每次调用等价于f.read(8192) -
iter(callable, sentinel)会持续调用该函数，直到返回值等于b""（文件末尾） - 数值 8192 不是 magic number，可根据 I/O 吞吐与内存平衡调整；1MB 以上反而可能增加系统调用开销
逐行读取时常见的隐形坑
看着简单，但生产环境里这几个点最容易翻车：
-
line末尾带\n（或\r\n），做字符串匹配前记得line.rstrip("\r\n")，别无脑strip()—— 会误删行首尾有意义空格 - Windows 下用
"r"模式读文本，Python 自动处理\r\n → \n；但用"rb"就不会，得自己 decode，且换行符仍是原始字节 - 某些日志轮转工具（如 logrotate）可能在读取中 rename 文件，Linux 下
open()仍能继续读（靠 inode），但 Windows 会抛PermissionError—— 这不是代码问题，是部署约束 - 用
enumerate(f)加行号？可以，但注意enumerate不改变原迭代行为，line还是带换行符的
真正难的从来不是“怎么读”，而是读的过程中怎么应对编码漂移、截断、权限突变和业务逻辑嵌套。这些没法靠一个 for 循环兜底。
