该故障本质是组件销毁后生成器仍持有并访问失活状态，导致静默脏数据泄漏；需通过AbortController、mounted标志、iterator.return()等机制管控生成器生命周期，并确保执行流真正终止。
这类故障本质是：组件已销毁，但生成器函数（或其返回的迭代器/异步迭代器）仍被外部持有，导致后续 next() 或 throw() 调用继续执行，并在闭包中访问已失活的组件状态。它不报错，但会悄悄更新旧引用、触发无效 emit、污染全局数据——属于典型的“静默型脏数据泄漏”。
盯住生成器的生命周期归属
Vue 或 React 中，生成器常用于封装分页拉取、流式处理、状态机逻辑。问题不在生成器本身，而在于谁持有它、谁驱动它、谁负责终止它。
- 避免在 setup() 或 useEffect 中直接创建并启动生成器，却不保存其引用以供清理
- 不要把生成器对象赋值给全局变量、静态属性、事件总线或缓存 Map —— 这些地方极易绕过组件卸载控制
- 检查是否用
for await...of遍历了异步生成器：该语法会隐式调用return()，但仅当循环正常结束；若提前退出（如组件卸载），return()不一定触发
强制中断异步生成器执行链
标准生成器没有内置取消机制，需手动注入终止信号。推荐在生成器内部监听 abort signal 或 isMounted 标志：
- Vue 3 中，在
setup()内配合onBeforeUnmount创建AbortController，并将signal传入生成器参数；生成器每次yield前检查signal.aborted - React 中可用
useRef(true)作为 mounted 标志，在生成器回调中读取该 ref 判断是否继续执行 - 对已存在的生成器，可在卸载时显式调用
iterator.return()（注意：仅对支持return方法的生成器有效，且需确保生成器内部有清理逻辑）
验证生成器是否真正停止
光清引用不够，要确认执行流确实终止：
- 在生成器关键 yield 点加
console.log('step X')，切换路由后观察是否仍有输出 - 使用 Chrome DevTools 的 “Memory” 面板拍快照，筛选关键词如
Generator或你的生成器名，对比卸载前后实例数 - 在生成器内写入调试标记：
const genId = Symbol('myGen');，并在所有 yield 前打点到全局 WeakMap，卸载时遍历并校验是否残留
避免副作用逃逸的设计习惯
生成器应只负责产出数据，不主动修改外部状态。脏数据往往源于生成器内部直接调用 emit、setState 或写入 ref：
- 把状态更新逻辑抽离到消费者侧（如
watchEffect或useEffect），生成器只 yield 新值 - 用
ref或useState接收生成器输出时，先判断组件是否存活再更新 - 对需要多次调用的生成器，优先考虑改造成 composable（Vue）或自定义 Hook（React），利用框架生命周期自动管理
