JavaScript scheduler.postTask 怎么安排前台与后台任务：优先级、取消和降级处理

搜索面板刚显示结果，缩略图索引和埋点清理又把主线程拖住，用户看到的不是“任务很多”，而是输入框按下去半秒才有反应。scheduler.postTask() 可以把这些工作分成用户阻塞、用户可见和后台三档，并让尚未开始的任务响应取消信号，但它不会凭空创建新线程，也不保证后台任务一定立即运行。

先把任务和用户感受对上

一个页面通常同时处理三类工作：点击后的即时反馈、会影响当前视图的渲染准备，以及可以晚一点完成的数据整理。把三类工作都塞进同一个长函数，浏览器只能按先后顺序执行，优先级自然无从谈起。

postTask 返回 Promise，回调的返回值会成为 Promise 的结果；回调抛错或任务被取消时，Promise 会拒绝。优先级只有三档，且默认是 user-visible。这里的“优先”是调度顺序，不是 CPU 配额，也不是并行执行。

最小写法：显式标出前台和后台

例如用户提交筛选条件后，先更新结果区域，再把不影响首屏的索引整理放到后台。示例中的检查点是 Promise 的成功结果和异常分支，而不是假设任务已经并行。

const runSearch = scheduler.postTask(
  () => renderResults(query),
  { priority: "user-blocking" }
);

const refreshIndex = scheduler.postTask(
  () => rebuildLocalIndex(items),
  { priority: "background" }
);

runSearch.catch(reportError);
refreshIndex.catch(reportBackgroundError);

如果一个任务只是更新当前页面可见但不阻塞点击的内容，可以选 user-visible。不要为了“看起来更快”把所有任务都标成最高档，否则调度器失去区分依据，后台工作仍会挤进同一条主线程。

取消必须发生在任务开始前

搜索词快速变化时，旧查询已经没有展示价值。把 AbortController 传给 signal，在新查询到来时取消旧任务；被取消的任务会进入拒绝分支，调用方要把 AbortError 和真正的业务异常分开处理。

let pendingController;

function schedulePreview(query) {
  pendingController?.abort();
  pendingController = new AbortController();

  return scheduler.postTask(
    () => renderPreview(query),
    {
      priority: "user-visible",
      signal: pendingController.signal
    }
  ).catch((error) => {
    if (error.name === "AbortError") return;
    throw error;
  });
}

取消信号只解决“尚未执行的排队任务”。如果回调已经开始，回调内部的同步计算仍要自己设计可中断边界；把一个几十毫秒的循环包进 postTask，并不会让它自动变成可抢占代码。

动态调级和普通取消不是一回事

如果任务只需要固定优先级并支持取消，AbortController 足够了。只有当任务可能从后台升到用户可见，才考虑 TaskController；这时不要同时设置 options.priority，否则固定选项会覆盖信号上的动态优先级。

const controller = new TaskController({ priority: "background" });
const task = scheduler.postTask(syncVisibleCache, {
  signal: controller.signal
});

controller.setPriority("user-visible");
task.catch(reportError);

调级不是性能承诺。浏览器仍可能受到当前长任务、页面生命周期和设备资源影响，验收时应该观察输入延迟、任务完成率和取消后的业务状态，而不是只看任务提交是否成功。

不支持时怎样降级才不会改坏交互

这个 API 目前不是所有主流浏览器都支持。先做能力检测，再把优先级映射到普通 Promise 或 setTimeout 队列；降级分支至少要保留“前台动作先完成、后台动作可延后”的业务顺序。

function schedule(task, options = {}) {
  if ("scheduler" in globalThis) {
    return globalThis.scheduler.postTask(task, options);
  }

  if (options.priority === "background") {
    return new Promise((resolve, reject) => {
      setTimeout(() => Promise.resolve().then(task).then(resolve, reject), 0);
    });
  }

  return Promise.resolve().then(task);
}

降级不是把 API 名字换掉就结束。要检查：输入事件期间是否仍然先更新视图；旧查询是否会覆盖新查询；取消后的 Promise 是否被静默吞掉；后台任务积压时是否需要合并或丢弃低价值工作。

上线前用三个问题验收

第一，最高优先级任务是否真的对应用户动作，而不是一股脑包住初始化代码。第二，取消后有没有残留写入、重复渲染或旧结果回填。第三，在不支持该 API 的浏览器里，页面核心动作是否仍然可用，后台工作是否有合理的延迟和合并策略。

常见问题

scheduler.postTask 会启动新的线程吗？

不会。它仍然是在浏览器的调度模型中安排任务，页面脚本的同步计算仍可能阻塞主线程。真正重的计算要结合 Web Worker，并在任务边界上重新设计数据传递。

priority 写成 background 就一定最后执行吗？

不一定。它表达的是相对优先级，实际执行还受已有长任务、页面状态和浏览器实现影响。应把它当作调度提示，并用用户可感知指标验收。

只想取消任务也要用 TaskController 吗？

不需要。只取消可以传 AbortSignal；需要改变任务优先级时再用 TaskController，并避免同时设置固定的 priority。

把任务分类、取消和降级放在同一层封装后，页面代码更容易说明“这项工作为什么现在做、什么时候可以不做”。真正上线前仍要在目标浏览器和真实交互路径上验证，而不是把 Promise 成功当成体验已经改善。