HTML本身无原生优先级任务调度机制，所谓“HTML优先级调度”实为开发者基于requestAnimationFrame、requestIdleCallback等浏览器原语在JS层手动构建的多队列调度模式。
HTML 本身没有 Prioritized Task Scheduling 这个原生机制，也没有叫这个名字的 API 或属性。所谓“HTML 的优先级任务调度”，是开发者在 JS 层基于浏览器调度原语（如 requestIdleCallback、requestAnimationFrame、queueMicrotask）手动构建的模式，不是 HTML 标签或解析器的功能。
为什么不能靠 <script></script> 标签的 defer 或 async 控制交互/后台优先级
很多人误以为把脚本标记为 async 就等于“低优后台任务”，其实不是：
-
async只影响脚本下载与执行时机：它让脚本异步下载、一就绪就立即执行（打断当前 JS 执行流），和任务优先级无关 -
defer是按文档顺序延迟到 DOM 解析后执行，仍属高优同步路径，可能阻塞交互响应 - 它们都不感知业务语义——点击按钮要立刻反馈，和上报埋点日志，对浏览器来说都是“一个 script 执行”
- 真正需要区分优先级的，是脚本内部发起的逻辑调用，不是脚本加载本身
queueMicrotask 不是优先级开关，而是微任务“投递器”
你不能靠多调几次 queueMicrotask 让某个任务“更优先”。它的行为非常确定：
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 所有
queueMicrotask回调严格 FIFO，先入队的一定先执行 - 它不支持参数指定优先级，也没有
queueMicrotask({ priority: 'high' })这种用法 - 如果在用户点击事件中连续调用 10 次
queueMicrotask，它们会全部挤在本轮微任务末尾，反而可能延迟渲染帧 - 想实现“交互任务插队”，必须自己维护多个队列（比如
immediateQueue和backgroundQueue），再用一次queueMicrotask触发统一调度循环
真正起效的优先级调度，靠的是分层 + 主动轮询 + 帧节奏绑定
参考 pdf2htmlEX 和现代前端调度器实践，关键不在单个 API，而在结构设计：
立即学习“前端免费学习笔记（深入）”；
- 用闭包封装任务，固化创建时的状态（如 DOM 引用、event timestamp），避免执行时取到过期值
- 维护两个私有队列：
immediateQueue（存按钮反馈、表单校验等）和backgroundQueue（存日志、预加载、非关键计算） - 调度循环绑定
requestAnimationFrame（保交互响应） +requestIdleCallback（捡空闲时间跑后台） - 禁止直接在事件回调里做重操作；统一走
scheduler.schedule(task, { priority: 'immediate' })接口 - 注意
requestIdleCallback在 Safari 中支持不全，需降级为setTimeout(..., 0)+ 时间切片模拟
最易被忽略的一点：优先级不是静态标签，而是动态权重。比如一个“保存草稿”任务，在用户连续输入时应降权（防抖），但当 tab 切走又切回时，应升权（避免丢失）。这要求调度器能感知上下文，而不是只看初始 priority 字段。
