浏览器 scheduler.postTask 怎么安排后台任务：优先级、取消与降级策略

列表页一边响应筛选，一边在后台计算统计摘要时，最容易出现一种“功能都完成了，点击却总要顿一下”的体验。原因通常不是某个函数单次执行太久，而是多个任务都挤在主线程队列里，后台计算和用户刚刚触发的交互没有明确优先级。浏览器的 scheduler.postTask() 可以把这类任务放进带优先级的调度队列，但它目前不是所有常用浏览器都支持，生产代码必须把能力检测和降级路径一起交付。

先把卡顿拆成可观察的任务

假设一个商品列表有三个动作：点击筛选后刷新结果、更新结果计数、在空闲时重新计算趋势摘要。三者都放进普通的 setTimeout，并不等于浏览器知道哪个更重要。它只能看到几个待执行回调，无法表达“筛选结果应该先让用户看到”。

先记录每类任务的开始和结束时间，至少区分交互触发、可见更新和后台计算。这样优化后的对比才有意义：不是笼统地说页面更快，而是看筛选后的可见结果是否先完成、后台摘要是否可以延后。

用 postTask 表达三档优先级

postTask 的优先级有 user-blocking、user-visible 和 background 三档。没有显式设置时默认是 user-visible。优先级表达的是调度意图，不是把任务变成并行线程，也不保证回调一定在某个固定毫秒数内运行。

const runFilter = (query) => scheduler.postTask(
  () => renderFilteredList(query),
  { priority: "user-visible" }
);

const refreshTrend = () => scheduler.postTask(
  () => calculateTrendSummary(),
  { priority: "background" }
);

runFilter("notebook");
refreshTrend();

筛选结果属于用户刚刚等待的反馈，趋势摘要则可以晚一些。不要为了追求“更高优先级”把所有任务都标成 user-blocking，否则队列失去区分，后台工作也可能持续挤压其他主线程任务。

需要取消时，把 signal 贯穿到任务边界

用户连续改动筛选条件时，旧的统计任务即使已经排队，结果也可能已经没有价值。可以用 AbortController 传递取消信号；如果还要动态改变优先级，则使用 TaskController，并且不要同时设置固定的 priority 选项。

let trendController;

function scheduleTrend(query) {
  trendController?.abort();
  trendController = new TaskController({ priority: "background" });

  return scheduler.postTask(
    () => calculateTrendSummary(query),
    { signal: trendController.signal }
  ).catch((error) => {
    if (error.name !== "AbortError") throw error;
    return null;
  });
}

这里的取消只阻止尚未开始或仍可被调度器取消的任务；如果回调已经开始执行，回调内部仍应按批次检查业务状态，必要时主动结束。捕获 AbortError 是正常的控制流，其他异常要继续抛出，不能把真实计算错误也吞掉。

动态调优先级要满足两个条件

当用户把列表滚动到趋势区域时，原本的后台任务可能变得更值得尽快完成。此时可以调用 TaskController.setPriority() 调高优先级：

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

if (isTrendVisible()) {
  controller.setPriority("user-visible");
}

动态调优先级只有在 signal 是 TaskSignal、且 postTask 没有另外传入固定 priority 时才成立。如果已经写成 { priority: "background", signal }，任务优先级就是不可变的，后续调用不会得到想要的效果。

能力检测要在入口处完成

Scheduler API 当前仍属于有限可用能力。先检测 globalThis.scheduler?.postTask，再选择实现路径；不要只检测 TaskController，因为任务提交入口和控制器是两个依赖点。

function enqueueBackground(work) {
  if (globalThis.scheduler?.postTask) {
    return scheduler.postTask(work, { priority: "background" });
  }

  return new Promise((resolve, reject) => {
    const timer = setTimeout(() => {
      try {
        resolve(work());
      } catch (error) {
        reject(error);
      }
    }, 0);
    // 需要取消时，保存 timer 并由调用方 clearTimeout(timer)。
    void timer;
  });
}

这个降级分支只保证“稍后执行”，不宣称拥有三档优先级。若后台计算很重，还应拆成小批次，在每批之间让出主线程，或转移到 Web Worker；不能用一个很大的 setTimeout 回调伪装成后台调度。

用同一组指标比较优化前后

测试不要只看控制台日志。选取同一批数据、同一设备和同一操作顺序，分别记录筛选触发到结果可见的时间、趋势摘要完成时间、被取消的旧任务数量，以及长任务是否仍然出现在 Performance 面板中。

如果结果可见时间下降，但后台摘要总耗时几乎不变，这是合理的：优先级改变的是等待顺序，不是计算本身。若长任务仍然阻塞交互，应继续缩小单次批量或转入 Worker，而不是继续提高优先级。

常见误区

把 postTask 当成多线程 API

它仍然在浏览器的调度体系中安排回调，不能替代 Web Worker。CPU 密集型任务本身仍会占用执行它的线程。

固定 priority 和 TaskController 混用

固定优先级会让任务不可动态修改。要调优先级，就只通过 TaskSignal 提供初始值和后续变化。

降级时继续承诺同样的调度语义

setTimeout 只能提供一个粗粒度的稍后执行入口。兼容方案应保持业务可用，并在需要时配合分片或 Worker，而不是声称和原生优先级完全等价。

上线前的最小验收

先在支持 Scheduler API 的浏览器中确认三档任务的顺序、取消后的 Promise 结果和动态优先级变化，再在不支持的浏览器中确认降级任务仍会执行、异常仍会向上抛出。最后用真实的筛选连续输入场景验证旧任务不会覆盖新结果。

如果文章中的示例要进入组件库，建议把能力检测封装成单一入口，把任务句柄、取消函数和指标记录一起返回。这样页面业务只关心“提交、取消、完成”，不会在每个组件里重复猜测浏览器能力。

常见问题

postTask 的默认优先级是什么？

没有设置固定优先级，也没有通过 TaskSignal 提供初始优先级时，默认是 user-visible。仍应按任务对用户的影响显式表达意图。

AbortController 和 TaskController 怎么选？

只需要取消时，AbortController 足够；还要在任务排队期间改变优先级时，使用 TaskController。两者都通过 signal 传给 postTask。

不支持 postTask 时能否直接跳过后台任务？

不建议默认跳过。可以退回可取消的定时器、分片执行或 Worker，并根据任务是否影响核心交互决定是否延后，但要保留错误处理和结果过期判断。

总结

scheduler.postTask 适合把“现在必须让用户看到”和“稍后完成也可以”的工作区分开。固定 priority 适合简单任务，TaskController 适合取消和动态调优先级；能力不足时则用明确的降级实现保持功能可用。真正的验收标准是交互反馈先完成、旧结果不会覆盖新结果，并且重任务在必要时被分片或移出主线程。