yield能压住内存峰值，因其按需计算并逐个产出值，不预先分配大内存容器；而列表推导式会一次性加载全部数据到内存。
直接用生成器（yield 或生成器表达式）能避开绝大多数 MemoryError，前提是别在下游把它又转成列表、不滥用调试打印、且清楚调用方是否支持迭代协议。
为什么yield能压住内存峰值
列表推导式如 [x**2 for x in range(10**7)] 会立刻分配约 80MB（假设每个 int 占 8 字节）并全部驻留内存；而 yield 函数或 (x**2 for x in range(10**7)) 只维持当前迭代状态和一个值，内存占用基本恒定在几 KB 级别——它根本没“存数据”，只是按需算一个、交一个、丢一个。
- 触发
MemoryError的关键不是“计算量大”，而是“构造容器时全量加载” -
yield不改变算法逻辑，只替换数据产出方式，迁移成本低 - 生成器表达式比生成器函数更轻量：没有函数调用开销，适合简单变换
哪些地方最容易把生成器“悄悄变回列表”
生成器本身很省内存，但下游一不小心就前功尽弃。常见翻车点：
- 调试时写
print(list(my_gen))—— 瞬间全拉进内存，尤其对大文件或数据库结果集 - 传给不接受迭代器的函数，比如
pandas.DataFrame(data=my_gen)，pandas 会内部调用list()展开 - 用
len(my_gen)或my_gen[5]—— 生成器不支持长度查询和索引，会报TypeError，但有人会先转 list 再取，等于白改 - 闭包中持有大对象引用，例如生成器函数里打开了一个未关闭的
open('huge.log')文件句柄，该文件对象无法被回收
分块读取文件时，生成器怎么写才真正安全
逐行读文件是最基础的流式处理，但“逐行”不等于“一行一 yield”就万事大吉——得看行本身是否巨大，以及下游是否批量消费。稳妥做法是显式控制块大小，并确保每块独立处理：
立即学习“Python免费学习笔记（深入）”；
- 文本文件按固定行数分块：
from itertools import islice+iter(lambda: list(islice(f, 10000)), [])，注意list(islice(...))是单块上限，不是全局加载 - CSV 优先用
pandas.read_csv(chunksize=5000)，它返回的是TextFileReader迭代器，每次for chunk in reader:拿到的是独立DataFrame，上一块自动释放 - 避免
f.readlines()和f.read().splitlines()，它们都是一次性全读进内存 - 如果必须用
requests.get()下载大文件，别碰response.content，改用response.iter_content(chunk_size=8192)并直接写入文件
生成器不是万能解药，这些情况它帮不上忙
生成器只解决“数据产出端”的内存压力，对以下问题无能为力：
- 下游逻辑需要随机访问或多次遍历（如要统计、排序、去重），生成器只能单向消费一次，此时得换分块 + 磁盘暂存（如
tempfile.NamedTemporaryFile） - 算法本身内存复杂度高，比如递归过深、维护超大缓存字典、或 numpy 数组中间结果爆炸，
yield无法降低这些结构的内存开销 - 多进程间传递生成器对象无效——
multiprocessing只能序列化实际数据，生成器不能被 pickle，必须在子进程中重建 - 内存泄漏：若生成器函数内长期持有全局大对象（如
cache = {}不清理），yield再干净也救不了
真正难的不是写出生成器，而是全程守住“不落地、不缓存、不重复展开”这条线——尤其在团队协作或调用第三方库时，很容易在某一层悄悄把迭代器又喂给了 list() 或 pd.concat()。建议在关键路径加断言：assert not isinstance(data, (list, tuple))，提前暴露隐式转换。
