scheduler.yield 怎么拆分大批 DOM 更新避免卡住交互

批量渲染列表、过滤大量节点或替换一整块页面内容时，最容易出现的体验问题是：用户已经点击了按钮，但选中状态、加载提示或滚动反馈迟迟不出现。原因通常不是 DOM API 本身不能用，而是一次任务把主线程占满了。scheduler.yield() 可以把长任务拆成多个可恢复片段，让浏览器有机会先处理输入和绘制；它不是把工作移到后台线程，也不会自动让每一段 DOM 更新变快。

适合的做法是先完成一个很短的交互反馈，再在批处理循环中等待 scheduler.yield()。运行前检测 globalThis.scheduler?.yield，不支持时用定时器切片，并在每次继续工作前检查任务是否已经取消。

本文围绕一个浏览器 API 展开，官方资料地址为 https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/yield。示例只展示静态代码关系，不代表在某个具体浏览器组合中已经完成运行验证。

先把用户能感知的反馈放到让步点前面

如果点击事件里先执行几千次节点创建，浏览器要等整个事件处理函数返回后才有机会绘制 spinner。第一步不是立刻改成复杂调度器，而是把即时反馈写在耗时循环之前，然后在真正的批处理函数里安排让步。

const button = document.querySelector('#render-button');
const status = document.querySelector('#render-status');
const list = document.querySelector('#result-list');

button.addEventListener('click', async () => {
  // 先更新短状态，让浏览器有机会在长任务前绘制反馈。
  status.textContent = '正在生成列表';
  button.disabled = true;
  try {
    await renderInChunks(list, createItems(2000));
    // 只有批处理正常结束，才把状态改成完成。
    status.textContent = '列表已生成';
  } catch (error) {
    // 取消和其他失败都要回收按钮状态，避免界面卡在禁用态。
    status.textContent = error.name === 'AbortError' ? '已取消' : '生成失败';
  } finally {
    button.disabled = false;
  }
});

这里的关键是顺序：反馈节点和按钮状态先更新，耗时工作交给后面的异步函数。不要把 scheduler.yield() 当成“自动并行”；它仍然在主线程上继续执行，只是把控制权交还给浏览器一小段时间。

在批量 DOM 更新之间插入 scheduler.yield

批处理时要同时控制两个量：每个片段做多少工作，以及片段之间何时让步。下面的实现按固定数量切片，适合每个条目成本比较接近的列表；如果单个条目的渲染成本差异很大，可以改成按时间预算切片。

async function renderInChunks(list, items, signal) {
  const chunkSize = 50;
  for (let start = 0; start 

把同一片段的节点先放进 DocumentFragment，再一次性追加，可以减少反复触碰真实 DOM 的次数；但它不替代让步。片段过大时，单次创建仍可能造成长任务；片段过小时，调度和函数调用开销又会增加。

给 scheduler.yield 准备能力检测和降级

MDN 将 Scheduler.yield() 标记为并非所有常用浏览器都支持的能力，因此页面不能无条件调用。支持时它返回一个 Promise，等待后继续处理；不支持时可以先用 setTimeout(..., 0) 把后续片段放回宏任务队列。降级不是等价实现：它没有相同的优先级继承语义，但能保留“把长循环拆开”的基本结构。

function yieldToBrowser(signal) {
  if (globalThis.scheduler?.yield) {
    // 原生让步能继续使用浏览器的优先级调度，并可继承任务取消信号。
    return globalThis.scheduler.yield();
  }
  return new Promise((resolve, reject) => {
    // 降级分支也监听取消，避免页面销毁后遗留等待任务。
    const onAbort = () => {
      window.clearTimeout(timer);
      reject(signal.reason);
    };
    const timer = window.setTimeout(() => {
      signal?.removeEventListener('abort', onAbort);
      resolve();
    }, 0);
    signal?.addEventListener('abort', onAbort, { once: true });
  });
}

能力检测要放在实际调用路径上，而不是只在构建时判断。这样同一份代码可以在支持该 API 的环境使用原生让步，在旧环境保留可接受的交互退让。若项目需要更细的任务优先级，可以进一步比较 scheduler.postTask()；不要为了一个列表渲染任务把所有工作都提升到高优先级。

取消和优先级边界要单独处理

scheduler.yield() 返回的 Promise 会在继续执行时完成，也可能因为继承到的 AbortSignal 而拒绝。取消并不等于自动撤销已经写入的 DOM，所以业务代码仍要在片段开始、等待之后或写入前检查信号，并决定是否清理已经插入的部分结果。

const controller = new AbortController();

async function startRender(items) {
  try {
    await renderInChunks(list, items, controller.signal);
  } catch (error) {
    // AbortError 或自定义 reason 都应进入统一的取消收尾逻辑。
    if (controller.signal.aborted) {
      list.replaceChildren();
      status.textContent = '渲染已取消';
      return;
    }
    throw error;
  }
}

cancelButton.addEventListener('click', () => {
  // 取消后，后续片段不会继续追加；已存在节点由收尾逻辑决定是否清理。
  controller.abort(new DOMException('用户取消渲染', 'AbortError'));
});

如果 yield() 位于 scheduler.postTask() 回调内部，它可以继承外层任务的优先级；这意味着同一段代码在不同调度上下文中可能有不同的继续时机。把优先级选择留在任务入口，组件内部只负责尊重取消和保持状态一致，通常更容易维护。

用四个问题判断卡顿是否真的被拆开

1. 反馈是否在长循环前：点击后应先看到按钮或状态变化，不能等全部节点创建完才更新。
2. 片段是否足够小：固定数量只是起点，单条记录包含复杂布局或图片处理时要重新估算片段成本。
3. 不支持时是否可继续：能力检测和 setTimeout 降级必须共用同一个批处理接口。
4. 取消后是否停止写入：等待前后的信号检查、按钮恢复和部分结果清理要形成闭环。

最后要区分“交互更快得到响应”和“总耗时更短”。scheduler.yield() 的主要价值是改善长任务期间的响应机会；如果每个片段本身做了昂贵计算，仍应考虑 Web Worker、缓存或减少 DOM 工作量。配图中的框和连线只是帮助理解代码职责，不能替代目标浏览器与辅助工具组合下的性能回归。

相关问题

scheduler.yield() 会把代码放到 Worker 中吗？
不会。它是在当前任务上下文中向主线程让步，后续代码仍在当前执行环境继续；需要隔离计算时应考虑 Worker。

为什么用了 yield() 页面还是卡？
通常是片段太大、每条 DOM 工作太重，或还有另一个同步长任务占满主线程。先缩小片段，再分别查看计算、布局和绘制成本。

可以用 setTimeout 永久替代 scheduler.yield() 吗？
可以作为兼容降级，但两者的调度优先级和继续时机不同。支持原生 API 时优先使用能力检测后的实现，并保留降级路径。

参考资料：https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/yield、https://developer.mozilla.org/en-US/docs/Web/API/Prioritized_Task_Scheduling_API。