微任务常见来源包括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 渲染、响应用户输入或执行其他宿主任务。
立即学习“Java免费学习笔记（深入）”；
-
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 更危险，因为浏览器无法在微任务中间插入渲染或中断。
