scheduler.postTask 不是浏览器标准 API，Chrome 122 已移除；可用 requestIdleCallback 模拟优先级调度，或用 Web Workers + MessageChannel 实现真正可控的时间片分配。
scheduler.postTask 不是浏览器标准 API
目前（2024 年中）所有主流浏览器都不支持 scheduler.postTask。它曾是 Chrome 实验性提案（Origin Trial 阶段），但已于 Chrome 122 版本正式移除，document.scheduler 和相关方法均已废弃。你如果在控制台输入 scheduler 或调用 scheduler.postTask，会得到 ReferenceError: scheduler is not defined 或 TypeError: Cannot read properties of undefined。
替代方案：用 requestIdleCallback 模拟优先级调度
requestIdleCallback 是唯一原生支持「让出主线程、等待空闲时机执行」的 Web API，虽不提供显式优先级参数，但可通过嵌套调用 + 超时控制实现粗粒度优先级区分：
- 高优任务：用
setTimeout(fn, 0)强制插队（牺牲响应性换及时性） - 中优任务：用
requestIdleCallback(fn, { timeout: 1 })，设极短超时逼迫尽快执行 - 低优任务：用
requestIdleCallback(fn, { timeout: 500 })，允许延迟最多 500ms
注意：requestIdleCallback 在页面后台或节流状态下可能被跳过，且 Firefox 未实现（需降级为 setTimeout + 时间切片）。
真正可控的主线程时间片分配：Web Workers + MessageChannel
若需严格按优先级抢占/让出 CPU 时间，必须离开主线程。推荐组合：
立即学习“前端免费学习笔记（深入）”；
- 把计算密集型任务全移到
Worker中执行 - 用
MessageChannel的port2在 Worker 内部实现微任务级调度（例如用port2.postMessage()触发下一个高优子任务） - 主线程仅通过
postMessage下发任务描述，不参与执行
这样既能避免阻塞渲染，又能通过 Worker 内部的优先队列（如用 Array.sort() 按 priority 字段排序）控制执行顺序——比任何主线程“伪调度”都可靠。
别信 polyfill，小心踩进 Promise 微任务陷阱
网上有些 scheduler.postTask 的 polyfill 实际只是封装了 Promise.resolve().then() 或 queueMicrotask()，这完全违背“调度空闲时间”的本意：
-
queueMicrotask会在当前任务结束后立刻执行，可能卡住渲染帧 - 它无法感知浏览器是否真有空闲，更不能设置 timeout 或 yield 给用户交互
- 在长列表滚动、动画进行时，这类 polyfill 会让页面直接卡死
真实场景里，优先级不是靠 JS 层“喊出来”的，而是由任务类型决定：DOM 更新必须同步，数据解析可延后，图像压缩必须离线——分清这点，比找一个不存在的 API 更重要。
