Python 3.3+允许生成器中return带值，等价于raise StopIteration(value)，易致管道中断；yield from会耗尽子生成器；同步I/O阻塞流水线；推荐命名生成器函数而非表达式。
生成器函数里 return 和 yield 混用会报错
Python 3.3+ 允许在生成器函数中使用 return，但只能返回 None 或带值的 return value；一旦用了带值的 return，就等价于抛出 StopIteration(value)。很多人误以为它像普通函数那样“结束并返回”，结果在管道下游收到意外的 StopIteration 异常或空值。
- 常见错误现象：
TypeError: 'int' object is not iterable或管道突然中断，尤其在用itertools.chain或嵌套for循环时 - 正确做法：如果要提前终止并传值，显式 raise
StopIteration(value)更可控；若只是退出，直接return（无值）即可 - 使用场景：构建带状态的数据过滤器，比如读取日志直到遇到某个 marker 行，然后把 marker 后的内容交给下一个阶段
用 yield from 链接多个生成器时要注意迭代器耗尽
yield from 看似是语法糖，实际会完全消耗子生成器——它不是懒求值的“引用”，而是把子生成器的每个产出项逐个 yield 出来。一旦被 yield from 过一次，该生成器对象就不可重用。
- 常见错误现象：对同一个生成器对象多次调用
list(gen)，第二次返回空列表；或在管道中重复使用同一生成器变量，后续阶段收不到数据 - 实操建议：每次需要新迭代时，重新调用生成器函数（如
parse_lines(file)），而不是保存生成器对象本身 - 参数差异：
yield from gen和for x in gen: yield x行为一致，但前者性能略优、且能透传.send()和.throw()
生成器管道里做 I/O 操作容易阻塞整个流水线
生成器本身不并发，如果在 yield 前执行同步 I/O（比如 requests.get()、open().readline()），整个管道就会卡住，无法实现“边生产边消费”的流式处理效果。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 使用场景：从多个 API 分页拉取数据、逐行解析大文件、实时日志 tail + 过滤
- 解决办法：把 I/O 操作移到生成器外部，用回调或队列解耦；或者改用
async def+async for（需配合aiohttp等异步库） - 性能影响：同步 I/O 在生成器里每调用一次，就多一次上下文等待；100 个请求串行执行，耗时≈单次 × 100，而非并发下的 ≈ 单次 + 网络 RTT
map/filter/reduce 类操作别直接套生成器表达式
像 (x * 2 for x in data) 这种生成器表达式很简洁，但它没有名字、无法复用、调试困难；更关键的是，它和 map、filter 的行为不完全等价——比如 map(func, gen) 返回的是一个惰性迭代器，但如果你把 gen 是个已耗尽的生成器，map 就不会报错，只会默默产出空序列。
立即学习“Python免费学习笔记（深入）”；
- 容易踩的坑：用
filter(lambda x: x > 0, gen)后再想对结果做二次sum()和len()，发现后者报错——因为filter返回对象不支持len() - 实操建议：复杂管道优先写成命名生成器函数，例如
def positive_ints(data):，方便单元测试、加日志、插桩调试 - 兼容性提醒：Python 3 中
map/filter返回迭代器，不是 list；若下游依赖索引访问，必须先转list()，但会失去流式优势
生成器管道真正的难点不在语法，而在于“谁控制生命周期”——上游是否可重入、下游是否及时消费、中间是否偷偷缓存或耗尽了迭代器。这些细节不报错，但会让数据无声丢失或延迟暴涨。
