JavaScript事件循环执行顺序取决于调用栈状态、任务队列及运行时实现；宏任务包括setTimeout、setInterval、setImmediate（Node.js）、I/O回调、UI渲染、postMessage、script脚本；微任务包括Promise.then/catch/finally、MutationObserver、queueMicrotask、async/await后续处理，且process.nextTick在Node.js中优先级最高。
JavaScript 的事件循环不是“先执行宏任务、再清空微任务队列”这么简单；真实执行顺序取决于当前调用栈是否为空、任务队列是否有待处理任务，以及浏览器或 Node.js 运行时的具体实现细节。
宏任务（macrotask）有哪些常见来源
宏任务是事件循环每次迭代中最多执行一个的任务单元。它们触发新一轮循环，也决定了代码的宏观节奏。
-
setTimeout和setInterval回调（即使延迟为 0） -
setImmediate（仅 Node.js） - I/O 回调（如
fs.readFile完成后） - UI 渲染（浏览器中，通常在一轮宏任务结束后尝试进行）
-
postMessage、MessageChannel消息事件 - 整个 script 脚本本身（初始执行上下文）
微任务（microtask）的插入与执行时机
微任务在每次宏任务执行完、且调用栈清空后立即执行，直到微任务队列为空。它不触发新循环，但会抢占渲染和下个宏任务。
-
Promise.then/catch/finally回调（包括Promise.resolve().then()） -
MutationObserver回调 -
queueMicrotask显式入队的函数 - async 函数隐式返回的 Promise 的后续处理（即 await 后的代码会被包装进微任务）
注意：process.nextTick（Node.js）优先级高于其他微任务，但它不属于标准微任务队列，而是在当前操作结束、进入事件循环前立即执行——这导致它甚至早于 Promise.then。
立即学习“Java免费学习笔记（深入）”；
一个典型执行序列的实操验证
下面这段代码能清晰暴露宏任务与微任务的真实穿插关系：
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。原因如下：
- 同步代码
console.log(1)和console.log(6)立即执行 - 两个
Promise.then被推入微任务队列，宏任务结束后立即执行，输出3和4 -
setTimeout的回调被推入宏任务队列，要等当前宏任务+所有微任务完成后，才在下一轮循环中执行，输出2 - 嵌套的
setTimeout在4输出后才注册，因此它的回调排在下一个宏任务位置，输出5
容易被忽略的关键点
微任务不是“比宏任务快”，而是“在宏任务退出后、下一轮开始前强制清空”。这意味着：
- 大量
Promise.then链或频繁queueMicrotask可能阻塞 UI 渲染（浏览器中微任务执行期间不渲染） - Node.js 中
process.nextTick会打断微任务队列，造成与浏览器不一致的行为 -
await后面的语句不是“立刻执行”，而是被封装进一个微任务——所以await Promise.resolve()后的代码，总在当前同步代码之后、下一个宏任务之前运行 - 没有“微任务循环”，只有“微任务队列清空”：一旦开始执行微任务，就必须全部跑完，中途不会插入新的宏任务
真正影响行为的不是任务“类型”本身，而是它们被推入哪个队列、以及当前事件循环阶段是否允许该队列执行。
