microtask 队列在每个宏任务执行完毕、js 控制权交还宿主环境时原子性清空，而非调用栈为空即执行；其触发依赖 microtasksscope 析构，确保 promise.then、queuemicrotask 等串行执行完才进入渲染或下一宏任务。

Microtask 队列不是“等整个事件循环结束才执行”，也不是“只要调用栈一空就立刻跑”，它的触发有明确、精细的时机点——关键在于JS 引擎控制权交还给宿主环境（如 Blink 渲染引擎）的那个瞬间。

微任务执行的真实触发点

根据 V8 源码和规范实践，microtask 并非在“调用栈为空”时被动检查执行，而是在JS 执行上下文即将退出、控制权即将交还给浏览器（Blink）或 Node.js 宿主时主动触发。这个交接点常见于：

• 一个宏任务（如 script 全局代码、setTimeout 回调、click 事件处理器）执行完毕，准备返回宿主
• Promise 构造函数内部同步执行完，resolve/reject 被调用后 JS 堆栈即将回退
• queueMicrotask() 被调用后，当前 JS 执行帧尚未退出
• MutationObserver 的回调执行结束后，控制权即将交还渲染线程

此时，V8 内部的 MicrotasksScope 作用域析构，自动检查并清空 microtask 队列——不是靠轮询，而是靠作用域生命周期驱动。

为什么手动点击和 button.click() 行为不同？

这正是 microtask 触发时机差异的典型体现：

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 手动点击：浏览器底层通过系统事件注入，每个 click 事件由独立的宏任务分发。两个监听器被当作两个**分离的宏任务回调**依次入队，因此第一个监听器执行完、microtask 清空后，才执行第二个监听器
• button.click()：JS 主动触发，整个调用链（包括所有注册的 click 监听器）都在同一个宏任务内同步执行。两个监听器按注册顺序立即运行，各自产生的 Promise.then 全部入 microtask 队列，待该宏任务彻底退出后，才一次性清空整个 microtask 队列

所以输出差异不是“Promise 本身行为变了”，而是宏任务的粒度不同导致 microtask 的触发时机不同。

microtask 队列清空是“原子性”的

一旦开始执行 microtask，引擎会持续从队列头部取出任务执行，期间新加入的 microtask（比如在 then 中又调用 then 或 queueMicrotask）会追加到队尾，并继续执行，直到队列完全为空。这个过程不会被任何宏任务或渲染打断。

• 这意味着：Promise 链、queueMicrotask 嵌套、MutationObserver 回调混合时，它们会全部串行执行完毕，之后才可能进入渲染或下一个宏任务
• 这也解释了为什么长时间运行的 microtask（如递归 queueMicrotask）会导致页面卡顿——它阻塞了渲染和用户交互的入口

与渲染和宏任务的协作关系

microtask 不是游离于事件循环之外的特殊存在，而是嵌套在标准流程中的关键环节：

• 每个宏任务执行完 → 立即清空 microtask 队列 → （浏览器）可选执行 UI 渲染 → 取下一个宏任务
• requestAnimationFrame 回调属于宏任务，但它在渲染前执行，位置介于 microtask 清空之后、实际绘制之前
• 注意：microtask 不会“插队”进正在执行的宏任务中间；它只在宏任务边界处爆发式执行

这种设计保证了高优先级逻辑（如 Promise 状态流转、DOM 变更响应）能及时生效，又不破坏事件循环的整体节奏。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南