17370845950

微任务常见来源包括Promise.then()/catch()/finally()、MutationObserver回调、queueMicrotask()及await后续代码；宏任务包括setTimeout/setInterval、I/O回调、UI渲染、postMessage等。

JavaScript 的微任务和宏任务不是两种“任务类型”，而是事件循环中两类不同优先级的回调队列。微任务总在当前同步代码执行完后、下一次宏任务开始前清空；宏任务则按顺序逐个从任务队列中取出执行。

微任务（Microtask）有哪些常见来源？

微任务由语言规范定义，触发后会被推入微任务队列，等当前调用栈清空后立即执行，且**必须一次性全部执行完**，中间不会插入任何渲染或宏任务。

• Promise.then() / .catch() / .finally() 的回调函数
• MutationObserver 的回调
• queueMicrotask() 显式调度的函数
• await 后续代码（本质是 Promise 链的微任务）

注意：Promise.resolve().then(...) 和 queueMicrotask(...) 是最直接、最可控的微任务入口；async/await 会隐式生成微任务，但堆栈更长，调试时容易误判执行时机。

宏任务（Macrotask）包括哪些典型操作？

宏任务代表一次完整的事件循环迭代起点，每次只取一个执行。它们之间天然存在“间隙”，浏览器可能在此间隙进行 UI 渲染、响应用户输入或执行其他宿主任务。

• setTimeout(fn, 0) / setInterval(fn, 0)
• setImmediate()（仅 Node.js，已废弃）
• I/O 回调（Node.js 中的文件读写、网络请求完成）
• UI 渲染（浏览器中的一帧更新，属于隐式宏任务）
• postMessage 和 MessageChannel 的消息处理

关键点：setTimeout(fn, 0) 并不等于“立刻执行”，它只是尽快把 fn 推入宏任务队列——实际执行要等当前宏任务 + 所有微任务都完成后，才轮到它。

微任务与宏任务的嵌套执行顺序怎么验证？

下面这段代码能清晰暴露事件循环的分层结构：

console.log(1);

setTimeout(() => console.log(2), 0);

Promise.resolve().then(() => console.log(3));

Promise.resolve().then(() => {
  console.log(4);
  setTimeout(() => console.log(5), 0);
});

console.log(6);

输出顺序是：1 → 6 → 3 → 4 → 2 → 5。解释如下：

• 同步代码先输出 1 和 6
• 接着清空微任务队列：两个 Promise.then 回调依次执行，输出 3 和 4
• 4 中的 setTimeout 是新的宏任务，被推入宏任务队列末尾
• 当前宏任务结束，开始下一轮：取出第一个宏任务（即最早那个 setTimeout），输出 2
• 再下一轮：取出第二个 setTimeout，输出 5

这个顺序不可靠地依赖“时间戳”或“执行快慢”，只取决于事件循环的排队规则。

为什么 await 不是微任务“开关”，而是一种语法糖？

await 本身不创建微任务，但它会让后续代码包裹进 Promise.then，从而进入微任务队列。例如：

async function f() {
  console.log('a');
  await Promise.resolve();
  console.log('b');
}
f();

等价于：

function f() {
  console.log('a');
  return Promise.resolve().then(() => {
    console.log('b');
  });
}

所以 b 总在所有同步代码和当前微任务之后执行。但要注意：如果 await 的是未 fulfilled 的 Promise，那 console.log('b') 就不会立即进入微任务队列，而是等到该 Promise settle 后才被调度——这正是异步流程控制的关键机制，也常被误认为“await 阻塞了微任务”。

真正容易被忽略的是：微任务队列没有“深度限制”，无限递归调用 queueMicrotask 或链式 Promise.then 会导致主线程无法交还控制权，页面卡死——它比 setTimeout 更危险，因为浏览器无法在微任务中间插入渲染或中断。