微任务队列处理任务的核心原则是：每个宏任务执行结束后，必须一次性清空当前全部微任务，且不跨轮次执行；即宏任务结束立即执行所有已入队及过程中新增的微任务，直至队列为空，期间不进入渲染或下一个宏任务。
微任务队列处理任务的核心原则是：**每个宏任务执行结束后，必须一次性清空当前全部微任务，且不跨轮次执行**。
强制清空，不遗留
只要当前宏任务（如脚本主流程、setTimeout 回调、click 事件处理）结束，事件循环就会立即检查微任务队列，并持续取出并执行任务，直到队列为空——哪怕中间不断新增微任务，也必须在本轮内执行完所有已存在的任务。它不会“留几个到下一轮”，也不会因队列变长而暂停。
- Promise.then()、queueMicrotask()、MutationObserver 回调一旦入队，就锁定在本轮执行
- 即使某个微任务里又调用 Promise.resolve().then(...)，新任务会追加到队列尾部，继续执行，而非推迟
- 清空完成前，浏览器不会进入渲染，也不会取下一个宏任务
有限执行，有兜底保护
虽然规则要求“清空”，但引擎不会任由代码无限嵌套或长时间占用主线程。实际运行中，V8、SpiderMonkey 等引擎都内置了防崩溃机制：
- V8 对连续微任务执行次数设限（通常几百到一千次），超限后主动中断，让出控制权
- 单个微任务若同步执行耗时过长（如几十毫秒），也会被强制打断，避免页面卡死
- 开发者看到 DevTools 报 “Potential infinite microtask loop”，就是这个保护被触发了
顺序确定，FIFO 基础不变
微任务队列本身遵循先进先出（FIFO）原则，任务入队顺序决定执行顺序：
- 先注册的 Promise.then 回调一定比后注册的先执行
- queueMicrotask(fn1) 在 queueMicrotask(fn2) 前调用，则 fn1 先于 fn2 执行
- 不同来源的微任务（如 Promise + MutationObserver）按注册时间混排，不按类型分优先级
不插队，也不越权
微任务优先级高，只体现在“时机早”——它总在宏任务之后、渲染之前执行；但它没有更高权限：
- 不能中断正在运行的同步代码
- 不能跳过其他微任务提前执行
- 不能绕过浏览器的健康检查（如渲染帧、输入响应）
- 一旦被引擎判定为异常持续占用，后续微任务可能被延后到下一轮甚至降级为宏任务调度
