Python 3.5+中StopIteration在生成器内被raise会转为RuntimeError，这是PEP 479强制规则；应改用return语句返回值，其value作为StopIteration.value被捕获。
Python 3.5+ 中，StopIteration 在生成器内部被 raise 会变成 RuntimeError，不是行为“不一致”，而是 PEP 479 强制改写的协议层规则——旧写法在新版本里直接失效。
为什么 raise StopIteration 在生成器里突然不工作了？
这不是 bug，是 Python 解释器主动拦截并转换异常。只要生成器函数体中显式 raise StopIteration（无论带不带参数），Python 3.5+ 都会把它转成 RuntimeError: generator raised StopIteration。目的是防止 StopIteration “逃逸”出生成器帧，干扰外层 for 循环或 next() 的终止判断逻辑。
- 常见错误现象：
raise StopIteration("done")没抛出StopIteration，反而卡住或报RuntimeError - 这个行为无法关闭：Python 3.5+ 默认启用，
from __future__ import generator_stop在 3.7+ 已无意义 - 协程（
async def）同样适用，不能raise StopIteration，必须用return
return 和 raise StopIteration 在生成器里到底差在哪？
两者都让生成器退出，但协议层面的语义完全不同：
-
return None或return→ 触发StopIteration，其.value是None -
return 42→ 触发StopIteration，其.value是42 -
raise StopIteration(42)→ 被拦截，抛出RuntimeError，原值42彻底丢失，无法通过.value获取 -
yield from subgen时，subgen的return值会成为yield from表达式的返回值；而raise StopIteration会直接崩掉整个委托链
为什么生成器表达式里 next() 耗尽会抛 RuntimeError 而不是 StopIteration？
因为异常实际发生在生成器表达式被迭代时，而非创建时。例如 part = (next(vid) for _ in range(size)) 只是定义，next(vid) 真正执行是在 for j in i: 这一行——此时外层 try/except StopIteration 早已退出作用域，根本捕不到。
立即学习“Python免费学习笔记（深入）”；
- 错误源头不在
part = ...这行，而在后续消费该生成器的地方 - Python 3.7+ 对未被捕获的
StopIteration统一转为RuntimeError，避免静默终止导致逻辑错乱 - 正确做法：把
next()调用和异常处理放在同一作用域，或改用next(iterator, default)提供默认值
如何安全地向调用方传递生成器结束状态？
别再依赖 raise StopIteration(value) 传业务数据。那不是它的职责：
- 用
return传终止值（仅限单值，如状态码、汇总结果） - 需要多字段信息时，
return一个namedtuple或字典，而不是塞进异常 - 非终止性错误（比如解析失败、校验不通过）应抛
ValueError、TypeError等明确语义的异常 - 第三方库（
itertools、yield from）全部按此规则实现，强行绕过只会让代码与生态脱节
最易被忽略的一点：这个变化不是“版本兼容问题”，而是生成器协议的根本重定义。所有试图用 sys.settrace、降级 Python 版本、或包装 raise 来绕过 PEP 479 的做法，都会让代码更脆弱、更难维护。
