微任务队列自身并不具备“可调节”的优先级属性——它本质上是一个严格遵循 FIFO（先进先出）原则的单一队列，所有微任务按照注册顺序依次执行，浏览器引擎不提供任何权重、插队或动态调整机制。这一点常被误解，有必要先厘清。
事件循环硬性规定微任务的执行顺序
浏览器和 Node.js 的事件循环机制明确：每个宏任务执行完成后，必须一次性清空整个微任务队列，中间不会插入任何其他任务。这意味着：
- Promise.then/catch/finally、queueMicrotask()、MutationObserver 回调都进入同一个微任务队列
- 先调用 queueMicrotask 或 .then 的任务就排在前面，后调用的无论如何都无法“插队”
- 即便你给某个任务标注了“高优先级”，只要它比另一个微任务晚入队，就一定晚执行
简而言之，微任务队列就像售票窗口前的队伍——先来后到，没有贵宾通道。
Node.js 的例外：process.nextTick
在 Node.js 环境中，process.nextTick 是一个特殊存在，它的优先级高于 Promise 微任务：
- 它在当前操作（如一次回调函数执行完毕）结束后立即执行，甚至早于所有 Promise.then
- 但它并非标准微任务，仅限 Node.js 环境，滥用可能导致 I/O 饥饿
- 浏览器环境没有 process.nextTick，不能跨平台依赖
需要注意，这个特例只存在于 Node.js，且设计初衷是让你在事件循环进入下一轮之前处理紧急回调，但绝不能把它当作通用的优先级控制工具。
想实现业务层优先级？需自行构建调度逻辑
真正可控的“优先级”，必须通过代码主动管理，而不是依赖微任务队列本身：
- 维护多个队列（如 highPriorityQueue、lowPriorityQueue），用 queueMicrotask 触发一次统一的调度器轮询
- 在轮询中按策略取任务：例如先清空高优队列，再处理低优；或按比例轮转
- 避免直接对每个高优任务都调用 queueMicrotask——这只会让它早入队，但无法阻止被其他微任务“夹在中间”
实现一个简单的调度器并不复杂，关键在于识别哪些任务需要优先处理，然后通过队列管理来控制执行顺序。
常见误区提醒
切勿将“微任务比宏任务快”误解为“能控制微任务内部顺序”：
- setTimeout(fn, 0) 再早，也排在所有本轮微任务之后
- Promise 构造函数里的代码是同步执行的，只有 resolve/reject 后的 .then 才进入微任务队列
- 大量嵌套 queueMicrotask 可能阻塞渲染和用户交互（Chrome 限制约 1000 层嵌套）
总结：微任务队列没有优先级，只有顺序；想实现优先级，请自己动手造轮子。
