微任务队列是随JavaScript应用复杂度提升逐步演进而来的执行机制，早期依赖宏任务导致响应不及时、DOM与数据不一致、回调地狱等问题；ES6通过Promise标准化微任务，使其在同步代码结束后立即执行；后续MutationObserver和queueMicrotask进一步增强控制力；如今async/await及主流框架均深度依赖微任务保障执行顺序与一致性。
微任务队列不是一开始就被设计出来的，而是随着 javascript 应用复杂度提升，逐步“长出来”的执行机制。
早期靠宏任务硬扛，问题明显
在 ES5 之前，异步基本全靠 setTimeout、setInterval 和事件监听器。它们都进入宏任务队列，由事件循环统一调度，但粒度太粗：
- 无法保证“同步代码一结束就立刻执行”，只能靠
setTimeout(fn, 0)抢时机，结果不可靠 - DOM 更新和回调混在一起，常出现“数据已改、视图没刷”的不一致
- 错误处理分散，嵌套回调（回调地狱）成为标配
- 开发者没法协调数据变化与 UI 渲染的节奏
Promise 带来转折：微任务正式入标准
ES6（2015）将 Promise 写进语言规范，同时隐式确立了其 .then/.catch 回调必须作为微任务执行——这是微任务第一次被标准化：
-
Promise.resolve().then()总在本轮同步代码结束后、下一轮宏任务开始前运行 - 它天然支持“插队”，比 setTimeout 更及时、更可预测
- 为 async/await 奠定基础：await 后续逻辑自动包装成微任务
接口持续扩展：从 MutationObserver 到 queueMicrotask
随着框架对响应式更新精度要求提高，浏览器陆续提供更底层、更可控的微任务能力：
- MutationObserver（2012 年起）虽非专为微任务设计，但其回调实际以微任务方式执行，被广泛用于监听 DOM 变化并延迟响应
- queueMicrotask()（2018 年提案，2020 年起主流支持）是首个显式暴露微任务队列的 API，绕过 Promise 构造开销，直接调度轻量逻辑
- Node.js 中 process.nextTick() 甚至比 Promise 微任务更早执行，体现运行时对优先级的差异化演进
如今已是基础设施，不再需要手动管理
截至 2026 年，微任务已深度融入运行时底层：
- async/await 编译后的暂停恢复逻辑完全依赖微任务队列调度
- Vue、React 等框架的响应式更新、effect 执行、组件挂载等关键路径，主动利用微任务保障顺序与一致性
- 开发者写
await或.then，引擎自动安排执行时机，无需关心插入细节
