微任务执行时机被浏览器硬性规定为每次渲染前必须清空，顺序为宏任务→全部微任务→渲染→下一个宏任务；它不参与调度竞争，而是紧贴宏任务末尾、渲染开始之前执行，确保dom修改与视觉呈现一致。
微任务与渲染过程的关系，核心在于“执行时机的强制绑定”——它不是靠抢时间赢来的优先级，而是被浏览器渲染管线硬性规定在“每次渲染前必须清空”的固定位置。
微任务是渲染的前置门槛
浏览器规范明确要求：每当一个宏任务（比如一次点击处理、一段 script 执行）结束、调用栈变空，引擎必须立刻执行所有已排队的微任务，且不中断、不穿插、不等待；只有等微任务队列彻底清空后，才允许进入渲染阶段。这个顺序不可跳过：
- 宏任务 → 全部微任务 → 渲染 → 下一个宏任务
- 哪怕在 Promise.then 里又调用 queueMicrotask()，新任务也会被纳入本轮执行，不会推迟到下次渲染前
- 而 setTimeout 回调属于宏任务，必然落在下一轮事件循环，中间可能插入用户交互、其他事件甚至一次完整渲染
它保障 DOM 状态与视觉呈现的一致性
很多关键逻辑依赖微任务在渲染前完成，否则逻辑和画面就会脱节：
- MutationObserver 需要拿到完整的 DOM 变更快照；如果渲染先发生，变更记录就可能被截断
- Promise.then 或 await 后续代码常用来读取刚写入的 DOM（如 innerHTML 更新后的 offsetHeight），这些值只有在渲染前读才是稳定可靠的
- Vue/React 的响应式更新利用微任务，确保状态同步与视图更新之间的因果链不被渲染打断
它不是“更快”，而是“不绕开渲染时机”
微任务并不比宏任务执行得更快，只是它不参与宏任务之间的调度竞争。它的执行窗口是确定的：紧贴在每个宏任务末尾、渲染开始之前。这个位置让它天然成为“DOM 修改之后、用户看到之前”的逻辑承载区：
- 你改了 class、插入了元素、触发了 reflow，这些变更已写入 DOM 树，但尚未绘制到屏幕上
- 此时 Promise.then 就能准确读取布局信息，而 setTimeout 则大概率要等到下一帧，期间 DOM 可能已被其他操作修改
它服务于浏览器的渲染节奏
渲染并非每轮事件循环都发生，而是由屏幕刷新率、页面是否激活等因素决定的“渲染机会（rendering opportunity）”。但无论是否实际渲染，微任务总是在这个机会到来前被执行——它是唯一能稳定衔接 DOM 操作与视觉呈现的异步通道。
