MemoryError频发源于Python一次性加载大数据至内存，优化核心是避免全量驻留：用生成器（yield）实现按需产出、内置迭代器（map/filter）惰性求值、分块读取（如pandas chunksize或islice）控制内存占用，并借助tracemalloc定位真实内存消耗层。
为什么MemoryError在读取大文件或构建大列表时频繁出现
Python 默认把整个数据一次性加载进内存，比如用 open().readlines() 读取 10GB 日志，或用 [x**2 for x in range(10**9)] 生成超长列表，会直接触发 MemoryError。这不是代码写错了，而是内存物理上限被突破——Python 解释器无法分配连续可用空间。
关键点在于：错误不是发生在计算过程，而是在「加载/构造」阶段。所以优化方向不是加速运算，而是避免全量驻留内存。
用生成器替代列表推导式，让数据“按需产生”
生成器函数（含 yield）不保存全部结果，只维持当前状态，每次调用 next() 或进入 for 循环时产出一个值。这对处理序列型大数据最直接有效。
- ❌ 错误写法（内存爆满）：
data = [process_line(line) for line in open('huge.csv')] - ✅ 正确写法（流式处理）：
def process_lines(filename):+yield process_line(line)，然后for item in process_lines('huge.csv'): - 注意：
list(generator)会立刻把所有值拉进内存，等价于原问题；应始终用迭代方式消费生成器 - 内置函数如
map()、filter()在 Python 3 中返回迭代器，天然惰性，可直接链式使用
分块读取文件或数据库，控制单次内存占用
对无法改造成生成器的场景（如依赖第三方库必须传完整 list），分块是更稳妥的兜底方案。核心是明确每块大小，并确保块之间无状态耦合。
- 文本文件按行分块：
with open('log.txt') as f:+for chunk in iter(lambda: list(islice(f, 10000)), []):（需from itertools import islice） - CSV 文件用
pandas.read_csv(chunksize=5000)，返回TextFileReader对象，支持for chunk in reader: - 数据库查询避免
cursor.fetchall()，改用cursor.fetchmany(size=1000)或启用服务器端游标（如 PostgreSQL 的name参数） - 块大小不是越大越好：过大会抵消分块意义，过小则 I/O 开销上升；通常从 1k–10k 行或 1–10MB 文件块开始试
生成器调试和意外内存泄漏的排查点
生成器本身不保数据，但容易因闭包引用、全局缓存或中间变量导致隐式驻留。这类问题不会报 MemoryError，但 RSS 内存持续上涨。
- 检查生成器内部是否无意中构建了大对象并赋值给局部变量（如
buffer = []然后不断append） - 避免在生成器里调用会缓存结果的函数（如某些 NLP 库的
tokenizer.encode()默认开启缓存） - 用
gc.get_objects()或tracemalloc定位增长对象类型，特别关注list、dict、str实例数量 -
yield后加del不起作用——Python 会在下一次next()前自动清理局部变量；真正要删的是你显式持有的引用（如类属性、模块级字典）
生成器和分块本身很简单，难的是判断哪一层在吃内存：是原始数据加载？中间转换结构？还是下游消费者偷偷转成了 list？遇到 MemoryError，先用 tracemalloc.start() 拍个快照，比盲目改 yield 有用得多。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
