yield能显著降低内存峰值，因为它返回迭代器而非完整列表，每次仅计算并产出一个值；例如range(10000000)生成列表需320MB，而yield或生成器表达式内存占用几乎不变。
为什么 yield 能显著降低内存峰值
因为 yield 不生成完整列表，而是返回一个迭代器对象，每次只在需要时计算并产出一个值。当你用 range(10000000) 构造列表时，Python 会一次性分配约 320MB 内存；换成 (x for x in range(10000000)) 或带 yield 的函数，内存占用几乎不变——只维持当前状态的几个变量。
什么时候必须用 yield 而不是 return
以下场景不改用 yield 就容易 OOM：
- 递归生成组合/排列（如矩阵列穷举、路径搜索），每层递归都
return一个新副本，会指数级堆积对象 - 流式处理大文件或数据库结果集，一次性
fetchall()加载全部行到内存 - Web 接口返回大量数据，后端拼成 list 再
json.dumps()，中间对象全驻留
典型反例：heavies() 函数中反复调用 mat_h.copy() 并 return，导致每个生成的矩阵都独立存在；改成 yield mat_h.copy() 后，上层 for 循环取一个、处理一个、引用释放一个。
yield 使用时最容易踩的坑
常见错误不是语法问题，而是语义误用：
立即学习“Python免费学习笔记（深入）”；
-
list(generator)会立刻把整个生成器展开成列表，前功尽弃 - 在生成器函数里修改传入的可变对象（如
mat_h），所有yield出的对象可能共享同一块内存，内容被后续迭代覆盖 - 忘记加
.copy()（如 NumPy 数组），yield mat_h实际是反复 yield 同一个数组对象的引用 - 用
yield from委托子生成器时，没确认子函数本身是否也用了yield—— 如果它return列表，委托就失效
配合 gc.collect() 的实际作用点
yield 本身不触发垃圾回收，但能缩短对象生命周期，让引用计数更快归零。只有在明确存在循环引用（比如类实例之间互相 hold）且你无法重构代码时，才需在关键节点手动调用 gc.collect()。更稳妥的做法是：在生成器循环体末尾显式 del 掉临时大对象，例如处理完一批数据后清掉缓存字典。
真正影响内存释放节奏的，从来不是 GC 阈值，而是你有没有让对象尽早失去所有引用——yield 提供了这个机会，但得你自己把握住。
