访问器属性不能直接控制generator执行节奏，而是作为触发器联动其启停与推进；generator负责产出数据流，访问器仅暴露状态、触发操作并保障节奏稳定。

访问器属性（get/set）本身不控制 Generator 的执行节奏，也不能直接干预异步迭代过程。它只是对属性读写行为的封装。所谓“精准控制 Generator 更新节奏”，本质是**将访问器作为触发器或状态桥接点，联动 Generator 的启动、暂停、推进与终止逻辑**，而非让 Generator 运行在访问器内部。

明确 Generator 与访问器的职责边界

Generator 函数（如 function*）负责产出数据流或执行序列化任务；访问器属性则应承担以下角色：

• 暴露可控的“开关状态”，例如 isPaused、stepCount、autoAdvance
• 在 set 中触发 Generator 的 next()、return() 或重置逻辑
• 在 get 中返回当前 Generator 的状态快照（如 done、value、pendingSteps），而非直接调用 next()

用访问器驱动 Generator 的典型模式

以富文本样式批量更新为例：需按字符/段落粒度逐帧应用样式，避免卡顿。可定义一个样式应用 Generator，并用访问器控制其节奏：

• 定义 Generator：返回 { value: node, done: boolean }，每次 next() 处理一个节点
• 绑定访问器：如 get nextStep() { return this.generator.next(); } —— 注意该 get 仅作单次推进，不自动循环
• 节奏控制入口：提供 set stepInterval(ms)，内部启动/清除 setInterval(() => this.nextStep, ms)；或 set manualStep(_) 触发一次 next()

避免常见误用

以下做法会导致节奏失控或不可预测行为：

• 在 get 中无条件调用 generator.next() —— 每次属性读取都推进，无法暂停或回退
• 把整个 Generator 实例挂到访问器上（如 get generator() { return this._gen; }），暴露底层迭代器，破坏封装性
• 在 set 中同步执行耗时 Generator 全量遍历 —— 阻塞主线程，失去“节奏”意义

配套机制保障节奏稳定性

仅靠访问器无法实现可靠节奏，还需结合：

• 取消信号：使用 AbortController 或自定义 isCancelled 标志，在 set 中中断正在运行的定时器或迭代循环
• 节流保护：在 set stepInterval 中限制最小间隔（如 ≥16ms），防止高频触发导致渲染撕裂
• 状态同步：当编辑器 Selection 变更或内容模型重置时，自动 generator.return() 并重建新 Generator，避免 stale 迭代