.throw() 是同步将异常注入当前 yield 暂停点，能否捕获取决于 yield 是否在 try 块内；未捕获则生成器关闭，资源清理须依赖 finally 而非 except。

生成器的 `.throw()` 不是“触发异常”，而是把异常直接注入当前 `yield` 暂停点——就像在那行代码手动写了 `raise exc`。所以，**关键不是“微任务穿透”，而是 yield 位置有没有被 try 包裹**。所谓“异步微任务穿透”其实是误解：`.throw()` 是同步调用，不经过事件循环，不存在“穿透”一说；真正的问题是开发者误以为异常会在生成器函数体顶层被捕获，而实际上它只作用于 yield 所在那一行。

必须把 yield 放进 try 块里

生成器不会自动捕获 `.throw()` 注入的异常。只有当 `yield` 表达式本身处于 `try` 语句的监控范围内，且对应 `except` 能匹配传入异常时，才能响应。

• 错误写法：`yield "ready"` 写在 `while True:` 循环开头，外层只有 `try` 包整个函数体——这无法捕获，因为异常发生在 yield 点，而 `except` 在函数入口之后、yield 之前
• 正确写法：`try: x = yield "ready" except ValueError: ...` —— yield 必须是 try 块内的直接语句
• 注意：`except GeneratorExit` 必须显式 `raise`，否则会被静默忽略（这是协议要求）

别依赖外部 try-catch 拦截 throw 的效果

你在调用方写 `try: g.throw(...)` 并不能让生成器内部“变得可捕获”。`.throw()` 抛出的异常是否终止生成器，完全取决于生成器内部是否处理了它。外部 try 只能捕获 `.throw()` 方法自身失败（比如对已关闭生成器调用），而不是它注入的异常。

• 若生成器内部没 catch，`.throw()` 会立即抛出原异常（如 `ValueError`），并使生成器状态变为 `CLOSED`
• 若生成器内部成功 catch 并 `yield` 或 `return`，`.throw()` 调用本身会返回下一个产出值，不抛异常
• 所以“防范”的重点永远在生成器定义侧，不在调用侧

配合 finally 做资源兜底，避免清理遗漏

即使你用 try-except 捕获了 `.throw()` 注入的异常，也不能保证资源一定释放。比如打开文件后在 yield 处被 `.throw()` 中断，except 块可能跳过清理逻辑。

• 所有关键资源（文件、连接、锁）必须放在 `try` 内部，并配 `finally` 块执行关闭
• 不要只靠 `except` 清理：`except` 只响应特定异常；`finally` 才确保无论 `.throw()`、`send()` 出错还是正常结束，都执行
• 示例：`try: f = open(...); yield ... finally: f.close()` —— 这样即使 `.throw(RuntimeError)` 进来，文件也会关

主动测试 throw 路径，别等线上崩

很多生成器只测了 `next()` 和 `send()` 流程，从不调用 `.throw()`，导致异常路径未经验证。建议在单元测试中显式覆盖。

• 对每个自定义异常类型，写一个 `g.throw(MyCustomError)` + 断言后续行为（是否 yield 恢复值、是否打印日志、是否释放资源）
• 特别检查 `GeneratorExit`：调用 `g.close()` 后再 `g.throw(...)` 应该报 `RuntimeError: generator ignored GeneratorExit`
• 用 `inspect.getgeneratorstate(g)` 辅助判断生成器当前是否 `GEN_SUSPENDED`，确保 `.throw()` 调用时机合法