JavaScript scheduler.yield 怎么让长任务主动让出主线程

在浏览器主线程上处理大数组、生成复杂视图数据或连续更新大量状态时，可以把工作拆成多个小批次，并在批次之间执行 await scheduler.yield()。它返回一个 Promise，把后续代码安排到未来的任务中，从而让浏览器有机会先处理用户输入、渲染等待办工作。它不会减少计算总量，也不会自动把代码搬到后台线程。

官方文档：https://developer.mozilla.org/en-US/docs/Web/API/Scheduler/yield

它解决的是单次占用过长，不是计算太慢

浏览器主线程一次只能执行一个任务。JavaScript 任务没有结束时，排队的点击、键盘输入和绘制机会只能等待。即使把一段代码拆成五个普通函数，只要它们仍在同一个调用栈里连续执行，对浏览器来说仍然是同一个任务。

scheduler.yield() 在代码中建立一个可恢复的让出点。调用后，当前 async 函数暂停；浏览器可以处理更紧急的工作；返回的 Promise 被兑现后，函数从原位置继续。默认续体采用 user-visible 优先级。如果调用发生在 scheduler.postTask() 任务内，续体还会继承该任务的优先级。

让出主线程的目标是缩短一次连续占用的时间，让页面更快响应，而不是让同一批计算凭空变少。

最小写法：在工作批次之间 await scheduler.yield()

最直接的方法是先确定一个批次大小。每个批次内部仍然同步运行，批次完成后主动交回执行权。批次大小应结合单项工作的复杂度和低性能设备表现调整，不能只按数组长度照搬。

async function processItems(items) {
  const batchSize = 100;

  for (let start = 0; start 

让出点之前创建的局部变量会按 async 函数的正常规则保留，因此可以继续使用索引、累计结果和配置。不过，暂停期间页面状态可能被用户操作改变。恢复执行时若依赖选中项、路由或组件是否仍挂载，应重新判断，而不是默认状态不变。

数据量不固定时，用时间预算比固定条数更稳

如果每条数据的处理成本差异很大，固定每 100 条让出一次可能忽快忽慢。可以用 performance.now() 记录当前批次已消耗的时间，到达预算后再让出。下面的 8 毫秒只是示例起点，不是浏览器标准或通用最佳值。

async function runCooperatively(items, budget = 8) {
  let chunkStart = performance.now();

  for (const item of items) {
    // 执行一小份可重复的同步工作。
    calculateItem(item);

    if (performance.now() - chunkStart >= budget) {
      // 时间预算耗尽时主动暂停，恢复后重新计时。
      await yieldToMain();
      chunkStart = performance.now();
    }
  }
}

这种写法适合工作量不均匀的解析、筛选和格式化。若单个 calculateItem() 本身就会占用很久，外层让出无法打断它，仍需继续拆小单项工作，或改用 Web Worker。

兼容处理：原生 yield 与 setTimeout 后备

MDN 目前仍把 scheduler.yield() 标为 Limited availability。支持检测应放在 globalThis 上，因为该接口也可以出现在 Worker 全局作用域。后备方案可以使用零延时定时器，把续体放入后续任务。

function yieldToMain() {
  // 优先使用专门为让出主线程设计的原生接口。
  if (globalThis.scheduler?.yield) {
    return globalThis.scheduler.yield();
  }

  // 后备方案只保证异步切换，不具备原生续体的优先级语义。
  return new Promise((resolve) => setTimeout(resolve, 0));
}

setTimeout(..., 0) 并不等于立即执行。回调会排到后续任务中；嵌套调用较多时，浏览器还可能施加最小延迟。原生 scheduler.yield() 的续体会进入增强优先级队列，同优先级下通常比普通 scheduler.postTask() 更早恢复，所以两种方案的调度顺序不能视为完全一致。

不要用 Promise.resolve 假装让出主线程

await Promise.resolve() 只把续体放入微任务队列。浏览器会在当前任务的微任务检查点继续清空微任务，通常不会因此获得处理另一个任务或完成一次绘制的机会。它适合整理异步控制流，却不能替代专门的任务让出机制。

async function ineffectiveYield() {
  doHeavyWork();

  // 这里只切到微任务，通常没有真正交回主线程调度权。
  await Promise.resolve();

  doMoreHeavyWork();
}

什么时候继续用主线程，什么时候转到 Worker

还要避免另一个常见误区：把所有 DOM 修改都放在循环内部。更稳妥的方式是先分批计算结果，再集中更新界面；否则即使频繁让出，布局和样式计算仍可能制造新的长任务。

如何判断改造是否有效

不要只看总耗时。让出后总耗时可能略有增加，因为调度本身也有成本。更重要的是观察一次连续任务是否变短、按钮反馈是否更快出现、输入期间是否仍能滚动或点击。测试时要覆盖普通设备与较慢设备，并用真实数据规模运行。

• 如果页面响应改善但处理结束时间接近原来，说明协作式分批达到了目标。
• 如果仍有单个工作步骤占用很久，继续拆分该步骤，而不是盲目增加更多让出点。
• 如果让出次数过多导致总耗时明显上升，增大批次或提高时间预算。

常见问题

scheduler.yield 会自动打断正在运行的函数吗？

不会。只有代码执行到显式的 await scheduler.yield() 时才会暂停。它不能抢占一个已经开始的超长同步函数。

可以直接取消一次 yield 吗？

yield() 本身没有参数，不能直接传入 AbortSignal。如果它运行在带信号的 scheduler.postTask() 回调中，则可以继承外层任务的取消信号。

每轮循环都调用一次是不是最流畅？

通常不是。过密的让出会增加调度开销。优先按批次或时间预算触发，再用真实交互表现调整阈值。