同步代码执行后，为何microtask queue优先级高于callback queue？

要理解这个问题，得从JS事件循环的设计初衷和实际场景的需求来看：

首先先明确两个关键事实：

• 同步代码执行完毕后，JS引擎会先清空所有微任务队列，再去处理宏任务队列中的任务
• async/await本质是Promise的语法糖，其后续逻辑会被包装成Promise的then回调，属于微任务；fetch的请求发起属于宏任务范畴，但请求完成后的then/catch回调会进入微任务队列

核心原因主要有三点：

1. 保证同步逻辑的状态一致性 #

同步代码执行过程中，可能会触发一些需要紧跟当前上下文完成的收尾操作，比如Promise状态变更后的回调。如果让宏任务先执行，会导致同步代码的状态还未完成更新，就被其他异步任务读取，引发状态不一致的问题。举个例子：

let count = 0;
function syncOperation() {
  count++;
  // 这个回调是微任务，会在同步代码执行完后立即执行
  Promise.resolve().then(() => {
    count *= 2;
  });
}
syncOperation();
// 微任务优先执行的话，这里打印的是2，符合同步逻辑的预期
console.log(count);

如果宏任务优先级更高，这里会先打印1，等下一次事件循环才会把count更新为2，破坏了同步逻辑的“原子性”。

2. 优化UI渲染的连贯性 #

浏览器的UI渲染操作是在宏任务队列的任务执行间隙触发的。如果把DOM更新相关的逻辑放在微任务中，会在当前事件循环的同步代码结束后立即执行，随后再进行UI渲染，不会出现“同步代码执行完先渲染旧DOM，再执行回调更新DOM”的闪烁问题。比如：

document.body.innerHTML = '加载中...';
// 模拟数据请求完成后的DOM更新
Promise.resolve().then(() => {
  document.body.innerHTML = '内容加载完成';
});

微任务优先执行的情况下，用户只会看到最终的“内容加载完成”，不会经历中间的“加载中”闪烁；如果是宏任务，浏览器会先渲染“加载中”，下一次事件循环才更新DOM，体验会大打折扣。

3. 让异步执行顺序更符合直觉 #

如果宏任务优先级更高，当同步代码触发多个嵌套异步操作时，会出现“先执行外层独立异步任务，再处理内层收尾逻辑”的混乱情况。微任务优先执行，能保证同一上下文触发的异步收尾逻辑先完成，再处理其他独立的异步任务（比如定时器、网络请求的发起逻辑），让异步代码的执行顺序更符合开发者的直觉。

补充：关于fetch的误区 #

很多人会误以为fetch的回调是宏任务，其实fetch的请求发起是由浏览器网络线程处理的宏任务，但请求完成后，其then/catch回调会被放入微任务队列——这是因为fetch返回的是Promise，而Promise的回调逻辑属于微任务，目的还是让请求结果的处理能紧跟当前同步上下文的收尾工作，避免状态滞后。

内容的提问来源于stack exchange，提问作者Chandni Dalal