不能在“全局未捕获异常网关”中通过迭代器 throw 拦截 generator 报错，因为 throw 是向生成器注入异常的主动控制手段，而非拦截机制；generator 异常逃逸需靠外层 try/except、sys.excepthook 或框架错误处理器兜底。
不能在“全局未捕获异常网关”中通过迭代器 throw 拦截逃逸的底层 Generator 报错——因为 throw 本身不是拦截机制，而是主动向生成器注入异常的控制手段；它不参与全局异常传播链，也无法替代 sys.excepthook 或框架级异常处理器。
Generator 的异常逃逸路径是独立的
生成器（generator）内部抛出的异常（如 KeyError、ValueError）若未在生成器函数体内被 try/except 捕获，会直接沿调用栈向外传播：
→ 从 next() / send() / throw() 调用点抛出
→ 若该调用点也无 except，则继续向上，最终触发 sys.excepthook
注意：throw() 是你“手动往生成器里扔异常”，不是“捕获它往外跑的异常”。它常用于协程通信或强制退出生成器，和“拦截未捕获异常”完全相反。
真正能拦截 Generator 逃逸异常的方式
-
在驱动生成器的外层加 try/except：所有对
next(g)、g.send(...)、list(g)等操作都必须包裹在try中，否则异常必然逃逸 -
统一注册
sys.excepthook：可捕获包括 Generator 逃逸在内的所有未处理异常，但属于兜底日志+告警，无法恢复执行或返回友好响应 -
Web 框架中补充
@app.errorhandler(Exception)（Flask）或@ExceptionHandler(Exception.class)（Spring Boot）：仅覆盖 HTTP 请求生命周期内的异常；Generator 若在后台线程、定时任务或非请求上下文中运行，仍需单独防护 -
避免让 Generator 抛原始异常：在生成器内部做防御性处理，例如用
yield default_value if key not in data else data[key]替代直接data[key]，把KeyError消解在源头
什么时候才该用 generator.throw()
它适用场景非常明确：
- 向正在暂停的生成器注入一个异常，模拟其内部出错（比如测试清理逻辑）
- 在协程中主动中断执行流，触发生成器的
except块或finally清理 - 配合
yield from实现异常委托传递（子生成器异常可由父生成器统一处理）
例如：
def subgen():
try:
yield 1
yield 2
except ValueError as e:
print("subgen caught:", e)
yield "handled"
<p>g = subgen()
print(next(g)) # 1
g.throw(ValueError("boom")) # 触发 subgen 内部 except，输出并 yield "handled"</p>生产环境 Generator 异常防护建议
- 禁止裸调用
next(g)—— 总是配try/except StopIteration, Exception - 用装饰器封装生成器调用，自动补全错误上下文（如当前批次 ID、输入参数快照）
- 对关键数据流生成器，添加
__iter__包装类，在__next__中做统一异常转换（如将OSError转为业务DataUnavailableError） - 日志中记录
g.gi_frame.f_lineno和g.gi_code.co_name，定位具体哪一行 yield 出问题
