yield比return更省内存，因为yield使函数变为生成器，不一次性加载所有结果到内存，而是按需逐个产出值并挂起状态；例如读取百万行日志时，return需全载入列表易OOM，yield则一行一行输出，内存占用基本恒定。
yield 为什么比 return 更省内存？
因为 yield 让函数变成生成器，不一次性把所有结果装进内存，而是每次调用只产出一个值，用完就挂起，下次从断点继续。比如读取百万行日志文件，用 return 得先全读进列表——可能直接 OOM；而用 yield 可以一行一行吐，内存占用基本恒定。
关键区别在于：带 yield 的函数返回的是 generator 对象，不是具体值；它只有在被迭代（如 for 循环、next()）时才真正执行到 yield 行，并暂停保存当前栈帧状态。
写一个能实际跑起来的 yield 示例
别一上来就写复杂逻辑，先验证基础行为是否符合预期：
def count_up_to(n):
i = 0
while i < n:
yield i
i += 1
<p>gen = count_up_to(3)
print(next(gen)) # 输出 0
print(next(gen)) # 输出 1
print(list(gen)) # 输出 [2] —— 注意：前两次已消耗掉 0 和 1，只剩 2-
next()触发一次 yield 执行，停在 yield 行；再调用又从下一行继续 - 生成器只能遍历一次，用完即空；想重用就得重新调用函数创建新生成器
- 用
list(gen)会一次性取尽剩余所有值，适合小数据，但会失去“懒加载”优势
yield 在真实场景中怎么避免常见坑？
最常踩的坑是误以为 yield 是“返回值”，结果写出无法复用或状态错乱的代码：
立即学习“Python免费学习笔记（深入）”；
- 别在 yield 后面写清理逻辑（比如
finally块里的 close()），除非用try/except/finally+yield显式控制——否则生成器被垃圾回收时不一定触发 - 不要在生成器里修改外部可变对象（如传入的 list），多个迭代器共享同一引用会导致意外交互
- 如果需要支持多次迭代，得包装一层：返回
count_up_to(n)而不是count_up_to(n)()—— 后者直接执行了生成器并返回空迭代器 - 调试时别用
print(gen)看不出内容，得用list(gen)或循环打印；但线上环境慎用list()，尤其数据量大时
yield from 是干啥的？什么时候必须用它？
当你要从另一个生成器、迭代器或可迭代对象里“转发”产出项时，yield from 比手动 for + yield 更简洁、更高效，且能正确传递 .send()、.throw() 和 .close()。
def chain_generators():
yield from range(2)
yield from ['a', 'b']
<p>list(chain_generators()) # [0, 1, 'a', 'b']- 不用
yield from时，你得写for x in range(2): yield x，多三行且容易漏处理异常 -
yield from会自动处理子生成器的 StopIteration，并让父生成器继续往下走 - 嵌套太深时（比如 yield from yield from …），调试堆栈会变长，出错时定位 yield 点不如平铺逻辑直观
生成器的边界很清晰：它不缓存历史值，不支持索引和 len，也不支持 rewind。这些限制不是缺陷，而是设计选择——一旦你开始想“能不能倒着遍历”或“能不能跳到第 1000 个”，说明该考虑是否真需要生成器，还是该换回普通列表或使用 itertools.islice 等工具做切片。
