列表推导式触发MemoryError是因为它一次性将全部结果加载进内存，而生成器通过yield逐个产出可保持恒定内存占用，但需调用方支持迭代协议且避免下游转回列表。
为什么列表推导式会触发 MemoryError
当你用 [func(x) for x in huge_iterable] 处理百万级数据时，Python 会一次性把全部结果塞进内存——哪怕每个元素只占 100 字节，一千万个就是 1GB。这不是代码写错了，是数据规模和数据结构不匹配的典型表现。常见于读大文件、遍历数据库结果集、解析超长日志等场景。
关键点在于：你未必需要“所有结果同时存在”，可能只是逐个处理、过滤或转存。此时列表是冗余容器，生成器才是更贴切的抽象。
yield 怎么一步步替换列表构建逻辑
把一个返回列表的函数改成生成器，核心就两步：删掉方括号/中括号包围的表达式，用 yield 逐个产出。注意不是所有地方都能直接换，得看调用方是否支持迭代协议。
- 原写法：
def get_all_squares(nums): return [x**2 for x in nums]→ 内存峰值随nums长度线性增长 - 改写后：
def get_all_squares(nums): for x in nums: yield x**2→ 内存占用恒定（仅存当前值和迭代器状态） - 调用方需适配：原来用
for s in get_all_squares(big_list)没问题；但若写了len(get_all_squares(...))或get_all_squares(...)[5]就会报错——生成器不支持随机访问和长度查询
哪些情况不能光靠 yield 解决
yield 只解决“产出端”的内存压力，但下游逻辑可能悄悄把生成器又转成列表，让优化前功尽弃。常见陷阱：
立即学习“Python免费学习笔记（深入）”；
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 误用
list(gen)：比如为了调试打印，随手加了print(list(my_generator()))，瞬间回到原点 - 传给不接受迭代器的函数：如
pandas.DataFrame(data=gen)会自动展开；应显式控制批次，例如用pd.concat([pd.DataFrame(chunk) for chunk in batched(gen, 1000)]) - 闭包持有引用：生成器函数内若引用了超大对象（如整个文件句柄、全局缓存字典），即使没
yield它，该对象也无法被回收
比 yield 更轻量的替代方案
如果连生成器函数的定义开销都觉得重，可直接用生成器表达式——它语法像列表推导式，但用圆括号，且不创建函数对象：
✅ 推荐：square_gen = (x**2 for x in range(10**7)) —— 占用内存极小，可直接用于 for 循环或 sum() 等消耗型函数
❌ 避免：square_list = [x**2 for x in range(10**7)] —— 触发 MemoryError 的高危写法
注意：生成器表达式只能用一次，第二次遍历时为空；需要复用时，要么重新创建，要么转为 itertools.tee（但会额外缓存）
真正难的不是写出 yield，而是判断哪里“必须存全量”、哪里“只需流式处理”。很多 MemoryError 其实暴露的是数据流设计缺陷，而不是某一行代码的问题。
