宏任务之间无内置优先级配置，执行顺序取决于插入队列时机、宿主调度倾向（如用户事件、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 间接影响主线程节奏
