微任务队列本身没有可设定的优先级，它严格遵循fifo原则；process.nexttick是node.js特例，优先级高于promise微任务，但不属于标准微任务，且浏览器不支持。
微任务队列本身没有“可设定”的优先级——它是一个严格遵循 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，不可跨平台依赖
想实现业务层优先级？得自己建调度逻辑
真正可控的“优先级”，必须靠代码主动管理，而不是依赖微任务队列本身：
- 维护多个队列（如 highPriorityQueue、lowPriorityQueue），用 queueMicrotask 触发一次统一调度器轮询
- 在轮询中按策略取任务：例如先清空高优队列，再处理低优；或按比例轮转
- 避免直接对每个高优任务都调用 queueMicrotask——这只会让它早入队，但无法防止被其他微任务“夹在中间”
常见误区提醒
别把“微任务比宏任务快”误解为“能控制微任务内部顺序”：
- setTimeout(fn, 0) 再早，也排在所有本轮微任务之后
- Promise 构造函数里的代码是同步执行的，只有 resolve/reject 后的 .then 才进微任务队列
- 大量嵌套 queueMicrotask 可能阻塞渲染和用户交互（Chrome 限制约 1000 层嵌套）
