生成器内try-catch无法捕获外部迭代错误，关键在于解耦状态更新与迭代控制：生成器只产出纯指令，由外部安全执行；推荐async generator+中间件模式，统一错误处理与原子化状态更新。
生成器函数内部的 try-catch 无法直接捕获外部迭代过程中的错误（比如 next()、throw() 或 return() 触发的异常），更不能“避免污染全局状态树”——因为错误是否影响状态，取决于你**在哪里更新状态、何时更新、以及错误发生时是否已执行了副作用**。关键不在“巧用生成器内的 try-catch”，而在于**把状态变更与迭代控制解耦，并将副作用推迟到安全时机**。
状态更新必须与迭代步骤严格分离
不要在 yield 表达式中直接修改全局变量或 Vuex/Pinia store：
- ❌ 错误示例：
yield store.count++—— 若该行抛错（如 store 未定义），状态已脏，且错误发生在 yield 期间，无法被生成器内部try捕获（因yield不是函数调用，不构成执行上下文入口） - ✅ 正确做法：生成器只负责产出纯数据或指令，由外部消费者决定是否/如何应用。例如 yield 一个描述动作的对象：
{ type: 'INCREMENT', payload: 1 }，再由统一的 reducer 或 action handler 执行更新
用 throw() 主动注入错误并集中处理
当迭代逻辑需响应错误（如 API 请求失败），应让生成器主动 yield 错误信号，或通过 iterator.throw(err) 通知生成器中断流程：
- 生成器内可设
try { yield … } catch (e) { /* 处理由 throw() 注入的错误 */ }，但仅对显式调用throw()有效 - 更稳妥的是：在外部调用
next()后检查返回值{ value, done, error? }（需约定协议），或用Promise包装每步 yield（即 async generator），用await it.next()+try/catch控制流
全局状态树应具备原子性与快照能力
与其依赖生成器“不出错”，不如让状态系统自身防污：
- 使用不可变更新（Immer、solid-js store、Zustand 的
produce）或事务机制（Redux with redux-batched-actions） - 为关键流程设计“预检 → 提交 → 回滚”三段式：生成器 yield 预检结果（如
{ canProceed: true, data: … }），外部确认后再触发真实状态变更 - 对动态全局变量，可用 Proxy 拦截赋值，结合当前执行上下文标记（如
Symbol.for('in-safe-iteration')）做白名单管控
推荐替代方案：用 async generator + 中间件模式
比手动 try-catch 更健壮的实践：
- 写 async generator 函数，每步
yield一个 Promise（如yield fetch(...)） - 用封装好的 iterator runner（如
for await (const res of safeRun(myGen())) { ... }），其内部统一try/catch并隔离错误 - 状态更新统一走
dispatch(action)，且 action creator 自带错误边界（如自动加try/catch并 emit FAILURE action）
