scheduler.postTask 的浏览器任务优先级

Prioritized Task Scheduling API 可以把自有页面的工作标记为 user-blocking、user-visible 或 background。BotBrowser 支持在获授权的 fixture 中复现流程并记录可见的完成、顺序和回退状态，但不能控制操作系统调度器，也不能保证第三方网站观察到固定的队列顺序。当任务结果需要支撑应用的可见决策时，请同时参考浏览器性能测量和性能优化。

TL;DR

• 只有维持当前交互可用的短工作才使用 user-blocking，不要把它当作通用加速开关。
• 下一次渲染需要的工作使用 user-visible，可延后的维护工作使用 background。
• 每个发布的任务都保留 AbortSignal、有界回退路径和明确结果。
• 同时比较任务状态与可见结果；优先级只是调度提示，不是延迟保证。

Contents

• 选择优先级
• 发布并取消工作
• 构造回退路径
• 验证顺序但不过度推断
• 实践结论

选择优先级

WICG Scheduling APIs 提案定义了 scheduler.postTask()，可以带可选的优先级和信号把 callback 放入队列。user-blocking 是最强的提示，适合保持输入或反馈响应的短动作。user-visible 是支持下一次可见状态的默认选择。background 适合可以等待的维护，例如清理缓存或准备过期预览。

优先级不保证执行时间、公平性或绘制顺序。浏览器可能让出执行权、暂停文档、合并工作，或在任务运行前拒绝它。把选择绑定到可见结果：过滤结果可以是 user-visible，分析批次则属于 background。不要因为某个按钮启动了渲染流程，就把整条流程标成 user-blocking。

MDN 的 Scheduler.postTask() 参考记录了可接受的值和 TaskController 集成方式。需要作兼容性决策时，在运行时检查 API 并记录浏览器版本。方法存在也不代表长 callback 没有风险；应拆分重工作业，并在分片之间让出执行权。

发布并取消工作

发布每个任务前，先建立一个小型的所有者记录。记录应包含 taskId、priority、fixtureId、startedAt、finishedAt、outcome 和 cancelReason，不应包含页面文本、账号标识或完整 URL。这个标识把一个可见结果和一次队列决策关联起来，但不会变成长期用户画像。

const controller = new TaskController({ priority: 'user-visible' });
const record = { taskId: 'results-17', priority: 'user-visible', outcome: 'queued' };

const task = scheduler.postTask(
  () => {
    record.outcome = 'rendered';
    renderResults();
  },
  { signal: controller.signal }
);

cancelButton.addEventListener('click', () => {
  controller.abort('superseded');
  record.outcome = 'cancelled';
  record.cancelReason = 'superseded';
});

task.catch(error => {
  record.outcome = error.name === 'AbortError' ? 'cancelled' : 'failed';
});

{
  "fixtureId": "queue-01",
  "taskId": "results-17",
  "priority": "user-visible",
  "implementation": "native-postTask",
  "outcome": "rendered",
  "cancelReason": null,
  "visibleState": "results-ready",
  "browserVersion": "155.0",
  "viewport": "1280x800"
}

TaskController 只负责这一项任务的取消。执行前取消应产生 cancelled，不能被统计成一次缓慢成功。callback 抛出异常时，在应用保留可用错误状态后记录为 failed。保持 catch 处理器连接，因为未处理的 rejected promise 可能掩盖原始用户操作。

控制器不会中断已经执行的 JavaScript。长 callback 仍会一直阻塞主线程，直到它让出或返回。渲染多项内容时，处理一个有界分片，安排下一分片，并再次检查本次运行是否仍然有效。Chrome 的优先任务调度文章说明了这种协作模型；postTask 不会变成抢占式线程。

构造回退路径

选择首选路径前，检测 globalThis.scheduler?.postTask。回退实现仍应保留同样的可见结果和取消规则，可以使用普通排队 callback、setTimeout 或应用已有调度器。不要让后台工作悄悄升级成阻塞操作。

条件	首选路径	回退与预期结果
API 可用	postTask(callback, { priority: 'user-visible' })	记录 queued，最终产生相同的可见结果
API 缺失	没有 scheduler 对象	排队一个有界 callback，并保持操作可用
信号已取消	callback 前出现 AbortError	标记 cancelled，不要渲染过时数据
callback 抛错	任务 promise rejected	标记 failed，显示既有重试操作
工作已过时	当前 taskId 不再匹配	丢弃结果，保留更新后的状态

回退是应用契约，不是两个浏览器拥有相同 event loop 时序的证据。即使实现无法执行优先级，也要把它保留为元数据。这样比较结果可以诚实地显示 priority: background 与 implementation: timeout，而不会暗示原生调度已生效。

不要用无限循环执行所有排队 callback 的回退方案。大批量工作会重新制造该 API 要缓解的长任务问题。web.dev 的长任务指南建议拆分工作并测量可见影响。有界分片加停止条件更容易取消，也更容易在支持工单中解释。

验证顺序但不过度推断

使用包含三个任务和一次受控取消的合成 fixture。将 input-feedback 以 user-blocking 发布，将 results-render 以 user-visible 发布，将 cache-refresh 以 background 发布，然后记录每个任务的第一个可见状态和最终结果。真正有用的断言是当前交互仍可用，过时工作不会覆盖它。浏览器可能让出执行权或隐藏文档，因此不要断言普遍适用的顺序。

分别在 API 可用、移除 API、以及执行前取消 AbortController 的情况下重复 fixture。把 browserVersion、viewport、fixtureId 和 implementation 与结果放在一起。比较第一个变化的字段，不要收集无限制的追踪信息。如果 implementation 变化，检查 feature detection；如果 outcome 变化，检查取消与所有权；如果可见画面变化，检查 callback 的工作量。

当 callback 创建 worker 工作时，hardware concurrency 与 worker 规划说明 navigator.hardwareConcurrency 只是容量提示，不是队列保证；应把主机决策与 priority 分开。

使用浏览器 User Timing 性能测量记录 fixture 自有区间，并把时长与 scheduler 优先级结果分开。

BotBrowser 可以在获授权的浏览器上下文中加载这个声明式 fixture，并记录可见状态标签。它不能强制第三方 event loop、证明任务在绘制前运行，或保证某个浏览器构建实现该提案。受控复现只能说明该 fixture 和环境，不能外推到所有设备或网站。

队列遥测只保留必要字段。实用记录包括 fixtureId、taskId、priority、implementation、outcome 和有界时长区间。复核窗口结束后删除临时标识，不要导出 callback 参数或页面内容。优先级实验应改善自有交互，不能成为收集无关浏览器数据的理由。

重试任务时，创建新的 taskId，并将旧任务标为 superseded。导航或组件卸载时，取消自有控制器并释放引用。所有者已经消失后才完成的任务不能更新新路由。生命周期检查比快速路径截图更能发现生产缺陷。

相邻的运行指南覆盖其他边界：浏览器性能测量讨论如何测量自有区间，浏览器上下文扩展讨论页面 event loop 之外的租约和容量。本文只讨论浏览器任务队列，以及把优先级当作证据时的边界。

Public sources

• WICG Scheduling APIs
• MDN: Scheduler.postTask()
• Chrome for Developers: Prioritized Task Scheduling
• web.dev: Optimize long tasks
• BotBrowser: Automation consistency

实践结论

选择能维持当前可见契约的最低优先级，为任务附加自有 AbortSignal，并为没有 scheduler.postTask 的浏览器保留有界回退。记录 queued、rendered、cancelled、failed 和 superseded，不要把优先级当成延迟承诺。浏览器更新后重复相同 fixture，并把结果限定在该 fixture 与环境内。