Python 3.5+中，生成器内显式raise StopIteration会被自动捕获并转为RuntimeError，这是PEP 479的强制行为；应改用return语句返回值，其value将作为StopIteration.value被捕获。
StopIteration在生成器函数里被raise后为什么没抛出？
Python 3.5+中，StopIteration在生成器函数内部被显式raise时，不会像以前那样直接冒泡到调用方，而是被自动捕获并转换为RuntimeError。这是PEP 479引入的强制行为——防止StopIteration意外“逃逸”出生成器，干扰for循环或next()的正常终止逻辑。
常见错误现象：raise StopIteration没报错、程序卡住、或者抛出RuntimeError: generator raised StopIteration。
- 这是设计使然，不是bug；所有Python 3.5+默认启用该行为（无法关闭）
- 如果你在生成器里手动
raise StopIteration来提前结束，必须改用return语句 -
return value会触发StopIteration异常，且value会作为StopIteration.value被捕获（仅限return，不适用于raise）
return和raise StopIteration在生成器中的行为差异
两者都让生成器退出，但协议层面处理完全不同：
-
return None→ 等价于return→ 触发StopIteration，.value为None -
return 42→ 触发StopIteration，.value为42 -
raise StopIteration→ 被拦截，转为RuntimeError（无论是否带参数） -
raise StopIteration(42)→ 同样转为RuntimeError，原42丢失，无法通过.value获取
示例对比：
立即学习“Python免费学习笔记（深入）”；
def gen_with_return():
yield 1
return "done" # ✅ 正确：for循环自然结束，next()收到StopIteration.value == "done"
<p>def gen_with_raise():
yield 1
raise StopIteration("done") # ❌ Python 3.5+ 报 RuntimeError</p>如何安全地从生成器返回值并兼容旧代码？
如果旧逻辑依赖raise StopIteration(value)传递结果，迁移时必须重构。核心原则：只用return传值，用普通异常（如ValueError）表达非终止性错误。
- 不要试图绕过PEP 479（比如用
sys.settrace或降级到Python 3.4） - 若需向调用方传递多个状态，可
return一个元组或命名元组，而不是滥用StopIteration - 对协程（
async def），同样适用：不能raise StopIteration，必须用return - 第三方库如
itertools、yield from都严格遵循此规则；yield from subgen中，subgen的return值会成为yield from表达式的返回值
调试时怎么快速定位StopIteration误用？
当看到RuntimeError: generator raised StopIteration，说明某处生成器写了raise StopIteration。这不是环境问题，是明确的代码违规。
- 搜索项目中所有
raise StopIteration（注意大小写和括号内是否有参数） - 检查
yield函数是否被误当成普通函数调用（比如忘了加next()或for，导致raise在函数体顶层执行） - PyCharm/VS Code等IDE通常会在
raise StopIteration下标黄警告；mypy 0.9+也能检测该模式 - 单元测试中若用
list(gen())捕获结果，raise StopIteration会导致测试直接失败，而return则一切正常
最易被忽略的一点：这个限制对所有生成器对象生效，包括types.GeneratorType实例、yield定义的函数、以及yield from链中的任意一环——任何环节抛StopIteration都会被拦截。
