宏任务间的优先级：不同宏任务源的区别与处理

宏任务之间无内置优先级配置，执行顺序取决于插入队列时机、宿主调度倾向（如用户事件、rAF优先）及自建分层队列策略。

宏任务之间没有内置的“优先级配置”机制，JavaScript 引擎本身不区分 setTimeout 来的任务和 fetch 回调来的任务，也不识别哪个宏任务“更重要”。真正影响执行顺序的，是任务被插入宏任务队列的时机、宿主环境的调度策略，以及你如何主动干预。

宏任务插入时机决定实际先后

宏任务不是按代码书写顺序排队，而是按它们“被推入队列”的时间点排序：

• setTimeout(fn, 0) 和 setTimeout(fn, 3) 同时运行时，0ms 的回调会先到期、先进队，哪怕它写在后面
• 用户点击事件触发的回调，通常比刚注册的 setTimeout(10) 更早进入队列——因为点击发生得更早
• fetch.then 回调属于微任务，但 fetch 本身的网络响应完成之后，会触发一个宏任务（如 resolve 后的后续逻辑若用 setTimeout 包裹）；它的实际排队时间取决于网络延迟+解析耗时

浏览器对不同宏任务源有隐式调度倾向

虽然规范未强制规定优先级，但现代浏览器在实践中会对某些宏任务源做轻量级倾斜：

• 用户输入事件（click、keydown、scroll）：通常被赋予更高调度权重，避免输入卡顿。即使有大量 setTimeout 在排队，新 click 回调也常能较快被取出执行
• requestAnimationFrame 回调：虽属宏任务，但浏览器保证它在下一帧渲染前执行，且会尽量对齐刷新率（如 60fps），因此具有事实上的渲染时序优先性
• UI 渲染本身：不是 JS 可调用的任务，但它是事件循环中固定的宏任务环节，位于微任务清空之后、下一个宏任务之前，所有 JS 逻辑都需为它让路

靠手动分层队列实现可控优先级

当默认行为不够用，比如要保障动画更新快于日志上报，就得自己建规则：

• 维护多个独立队列，例如：uiQueue（高优）、networkQueue（中优）、analyticsQueue（低优）
• 用 requestIdleCallback 或定时检查空闲时间，在主线程宽松时批量处理低优队列
• 关键交互触发时（如 dragstart），可临时将相关任务插到高优队列头部，或直接用 queueMicrotask 同步推进状态更新
• 避免单个高优队列无限执行，建议限制连续执行数（如最多 3 个），防止饿死其他队列

注意跨源与资源竞争带来的间接影响

看似无关的宏任务源可能因底层资源争抢而互相干扰：

• 大量 setTimeout 或 setInterval 会持续占用事件循环入口，挤压其他宏任务的调度窗口
• 频繁的 postMessage 消息会生成宏任务，若目标窗口繁忙，消息队列可能积压，造成延迟不可控
• Web Worker 中的 message 回调也是宏任务，但其调度独立于主线程，不会直接抢占，却可能通过共享内存或 postMessage 间接影响主线程节奏