微任务队列优先级严格高于宏任务，是事件循环硬性规则：每轮宏任务结束后必须立即清空全部微任务，再取下一个宏任务；Promise.then 总先于 setTimeout(0) 执行，且微任务可递归追加。
是的，微任务队列的优先级总是高于宏任务——这不是“通常”或“一般情况”，而是 JavaScript 事件循环的硬性规则，由规范强制保证。
每次一个宏任务执行完毕后，引擎必须立即、全部清空当前微任务队列，之后才允许取下一个宏任务。这个“清空”动作不可跳过、不可延迟、也不受外部干预。哪怕微任务是刚被 queueMicrotask 插入的，只要它在本轮宏任务结束前入队，就一定在这轮末尾执行。
微任务一定先于宏任务执行的典型表现
-
Promise.then总比setTimeout(0)先运行，哪怕setTimeout先注册 -
queueMicrotask中新增的微任务，会在同一轮中继续执行（微任务可递归追加） - 即使在
setTimeout回调里写Promise.resolve().then(...)，该then仍会在当前setTimeout结束后、下个宏任务开始前执行
这背后没有“调度算法”或“优先级字段”，只有明确的执行阶段划分：
同步代码 → 微任务（全清）→ 一个宏任务 → 微任务（全清）→ …
所谓“特殊情况”，其实是误解或环境差异
有些看似打破规则的现象，并非微任务优先级失效，而是混淆了任务类型或执行上下文：
process.nextTick（Node.js）不是标准微任务
它比Promise.then还早，在当前操作结束后、任何微任务之前执行。但它属于 Node.js 特有机制，不适用于浏览器，也不能当作“更高优先级的微任务”来跨平台使用。requestAnimationFrame是宏任务，但时机特殊
它不进普通宏任务队列，而由浏览器在渲染帧前统一调度。它不会插队到微任务中间，也不会晚于setTimeout—— 实际顺序取决于是否在同一次事件循环中触发，但它从不比微任务更早执行。postMessage触发的回调是宏任务，但延迟极低
有人用它模拟“最低优先级”，但这只是利用了跨上下文通信的异步特性，延迟不稳定，不属于优先级调控手段。反复
setTimeout(0)不等于提高优先级
它只是不断往宏任务队列尾部追加新任务，无法改变已有任务的顺序，也无法抢在微任务前执行。
真正影响感知“优先级”的关键点
- 微任务不能跨宏任务保留：上一轮没执行完的微任务？不存在——每轮都清空，新微任务只能等下一轮宏任务结束
-
长时间微任务会阻塞渲染和输入响应：比如在
Promise.then里跑一个 100ms 的 for 循环，浏览器无法在本轮插入渲染，用户会感觉卡顿 - UI 渲染本身是宏任务：微任务执行完才会走到渲染阶段，所以大量微任务会推迟画面更新，即使逻辑很快
如何合理利用这个确定性
- 需要立刻响应用户操作或保持状态一致 → 用
Promise.then或queueMicrotask - 需要与页面渲染节奏对齐（如动画、布局读写）→ 用
requestAnimationFrame - 需要延后执行且不抢占关键路径 → 用
setTimeout(0)或requestIdleCallback - 需要分层调度不同紧急度的异步逻辑 → 自建队列（high/normal/low），用
queueMicrotask触发检查并择优取一个高优任务执行
微任务的高优先级是可靠的，但不是万能的。它的强大在于确定性，代价是不容打断。用得好，提升响应；滥用，反而导致饥饿或卡顿。
