微任务在当前宏任务执行完毕、调用栈清空后立即执行，且必须在下一个宏任务开始前和页面重绘之前完成；期间新产生的微任务会追加至当前队列尾部并一并执行。
微任务在事件循环中触发的时间边界非常明确：它发生在当前宏任务执行完毕、调用栈清空之后，且在下一个宏任务开始之前。这个“间隙”不是可选时机，而是 JS 引擎强制执行的固定环节。
触发前提：调用栈必须为空
微任务队列不会在任意时刻运行。只有当 JS 引擎完成当前宏任务的所有同步代码，并将调用栈完全清空时，才会启动微任务检查。例如：
- 一个
click事件处理函数是宏任务，其内部所有同步语句执行完、函数返回后，调用栈才真正为空； - 此时引擎立即扫描微任务队列，依次执行所有已排队的
Promise.then、queueMicrotask等； - 哪怕中间又产生新的微任务（比如某个
then回调里又调用了Promise.resolve().then(...)），也会被追加到当前微任务队列尾部，本轮一并执行，不会等到下一轮。
与渲染和宏任务的严格时序关系
在浏览器环境中，微任务的执行位于两个关键节点之间：
- 它一定在当前宏任务结束后、页面重绘（paint）之前发生；
- 它也一定在下一个宏任务（如 setTimeout 回调、另一个 click 事件）开始之前完成。
这意味着 DOM 变更 + 微任务组合可以实现“变更后立刻响应”，而无需等待渲染——这是 MutationObserver 能精准监听 DOM 更新的基础。
实际影响明显的边界案例
以下行为会直接决定微任务是否“立即触发”：
-
同步阻塞会推迟微任务：比如在宏任务末尾写一个长循环
while(Date.now() - start ，微任务要等循环结束、调用栈清空后才执行； -
异步操作不等于微任务：
new Promise((resolve) => { console.log('sync'); resolve(); })中的console.log是同步的，resolve()也只是安排后续微任务，并不触发执行； -
跨宏任务不共享微任务队列：两次
button.click()触发两个独立宏任务，各自执行完后分别清空自己的微任务队列，互不影响。
Node.js 与浏览器的一处关键差异
在 Node.js 中，process.nextTick 的优先级高于 Promise.then，属于“微任务中的微任务”。但在浏览器中，所有标准微任务（Promise.then、queueMicrotask、MutationObserver）按入队顺序执行，没有内部优先级之分。因此，浏览器里不存在“微任务嵌套抢占”的情况，时间边界更稳定、更可预测。
