read()和readlines()会爆内存是因为它们全量加载文件并构建对象，实际内存占用达文件体积2–4倍；安全做法是用for line in f逐行迭代或分块读取。
read() 会把整个文件一次性塞进内存，不是“突然”飙升，是设计如此——它本就要这么干。
为什么 read() 和 readlines() 一用就爆内存
这两个方法本质都是「全量加载」：read() 返回一个超大字符串，readlines() 返回一个包含几百万个字符串的列表。Python 字符串和列表本身都有额外开销，实际内存占用通常是文件体积的 2–4 倍。
- 10 GB 日志文件 →
f.read()可能吃掉 25 GB RAM - 500 万行 CSV →
f.readlines()构建的列表对象比原始文本还占内存 - 即使你只想要第一行，
readlines()[0]也得先把全部行都加载进来
你以为在“读文件”，其实是在“造对象”
Python 文件操作不是直接映射磁盘数据，而是解码、封装、建对象：
- 文本模式下，每行末尾的
\n被剥离又重建为新字符串对象 -
readlines()每行都是独立字符串，每个都带引用计数、类型头、哈希缓存 - 如果你紧接着做
content.splitlines()，等于又复制一遍——两份全量数据同时驻留
这不是 bug，是 Python 抽象层的必然代价。想省内存，就得绕过这一层封装。
立即学习“Python免费学习笔记（深入）”；
真正安全的读法：靠迭代器，而不是靠“读完再处理”
文件对象本身是可迭代的，for line in f: 是最轻量的逐行流式读取，每次只 hold 一行，不累积。
- ✅ 正确：
with open('big.log') as f: for line in f: process(line) - ❌ 危险：
lines = f.readlines(); for line in lines: process(line) - ⚠️ 注意：
line.strip()没问题，但lines = [line.strip() for line in f]就又全载入了
如果必须分块（比如按 8 KB 读），用 f.read(8192) 手动控制 size，别传负数或不传。
Excel 等二进制格式更危险：别信 pandas.read_excel() 的默认行为
.xlsx 是 ZIP 包，pandas.read_excel() 默认用 openpyxl 引擎，会解压全部 XML 并构建完整 DOM 树——100 MB 文件可能瞬时吃掉 3 GB 内存。
- ✅ 只读大 Excel：
load_workbook(..., read_only=True)+ws.iter_rows(values_only=True) - ✅ 大 CSV 替代方案：
pandas.read_csv(..., chunksize=10000)，返回可迭代的 DataFrame 分块 - ❌ 别写
df = pd.read_excel(...); df.to_parquet(...)—— 中间这个df就是内存炸弹
真正容易被忽略的点：不是“有没有读完”，而是“有没有让上一块数据彻底失去引用”。哪怕你用了生成器，只要 somewhere 存了 list(gen) 或 append 到全局 list，就前功尽弃。
