ESLint 本身不提供规则强制拦截“无 try-catch 的 generator throw 调用”，因其属运行时逻辑而非静态可判定模式；可通过组合 @typescript-eslint/no-floating-promises 等规则、ai-guard 插件及类型工具（如 NeverThrow）实现对 generator 错误传播路径的显式防护。
直接说结论：ESLint 本身不提供规则来强制拦截“无 try-catch 的 generator throw 调用”，因为这属于运行时控制流逻辑，而非静态可判定的语法模式。但你可以通过组合现有规则 + 插件 + 自定义策略，实现近似效果——重点不是“拦截 throw”，而是拦截未被防护的异步/生成器错误传播路径。
明确问题本质：throw 本身合法，危险的是“逃逸出作用域”
Generator 函数中 `throw` 是正常语义（如 `generator.throw(err)` 或内部抛出），真正风险在于： - 异步操作（Promise）在 generator 内部被 `.then()` 或 `await` 后未处理 rejection； - `yield` 返回的 Promise 被调用方（如 `for await...of` 或手动 `next()`）忽略 reject； - 错误在 generator 外部未被捕获，导致 unhandledrejection。所以目标不是禁止 `throw`，而是确保所有可能抛错的路径都有显式错误边界。
启用关键 ESLint 规则组合
以下规则需全部开启并设为 error 级别：- @typescript-eslint/no-floating-promises：防止 yield 或 await 后的 Promise 没有被链式 catch 或 try 包裹；
- @typescript-eslint/no-misused-promises：避免把 Promise 当布尔值用（如 `if (fetch())`），这种写法常伴随错误忽略；
- no-empty 和 no-empty-function：防止空 catch 块或空 generator 方法体，掩盖错误处理缺失；
- no-unsafe-finally（若使用 ESLint v8.50+）：确保 finally 中不引入新异常干扰主流程；
- no-ex-assign：禁止给 catch 参数赋值，避免覆盖原始错误信息；
搭配 ai-guard 插件强化 AI 生成代码防护
AI 辅助编码常在 generator 中遗漏错误处理，eslint-plugin-ai-guard 的 strict 预设能补上这类盲区：- 自动标记
catch (err) { console.error(err); }这类仅日志不 re-throw 的弱防护； - 检测
try { yield fetch(...) } catch {}中空 catch； - 识别硬编码密钥、敏感数据泄露等 generator 中易被忽略的安全反模式；
补充：用类型系统约束 generator 错误传播
单纯靠 ESLint 不够，建议结合类型工具：- 使用 NeverThrow 库包装 generator 返回值为
Result<T, E>，让 TypeScript 编译器强制你处理E分支； - 对 generator 函数签名做约束，例如：
function* safeFetch(): Generator<promise error>>, void, unknown></promise>； - 配合 eslint-plugin-functional 禁止副作用和隐式错误传递；
不复杂但容易忽略。
