17370845950

事件循环每轮只取一个宏任务，执行完后必须清空全部微任务队列才进入下一轮；同步代码属首个宏任务，故console.log('end')总在Promise.then之前输出。

事件循环怎么调度 Promise 和 setTimeout？

事件循环不是“先执行完所有宏任务再处理微任务”，而是每轮只取一个宏任务，但**必须清空当前全部微任务**后才进入下一轮。这是最常被误解的点。

比如你连续注册 5 个 Promise.then()，它们会一次性全部执行；但 5 个 setTimeout(..., 0) 会分 5 轮依次触发——哪怕时间都设为 0。

• 微任务队列在每次宏任务结束后立即“倾倒”，没有延迟
• 宏任务之间有明确边界：UI 渲染、用户事件、setTimeout 都算独立宏任务
• queueMicrotask() 和 Promise.then() 行为一致，但前者更语义清晰、无状态开销

为什么 console.log('end') 总比 Promise.then 先输出？

因为同步代码（包括整个 script 标签）本身就是第一个宏任务。它执行完才开始检查微任务队列——所以 console.log('end') 是同步阶段最后一步，而 Promise.then() 是紧接着的微任务阶段第一件事。

console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');

输出顺序固定为：start → end → promise → timeout。这不是“快慢”问题，是**执行阶段不可跳过**：同步 → 微任务 → 下一轮宏任务。

立即学习“Java免费学习笔记（深入）”；

Node.js 和浏览器的事件循环有啥实际差异？

对前端开发者影响最大的是：setImmediate() 和 process.nextTick() 在 Node 中存在，但浏览器里没有；而 MutationObserver 是浏览器特有微任务源。

• process.nextTick() 在 Node 中优先级高于 Promise.then()，但它不属于标准事件循环规范，仅限 Node 环境
• 浏览器中 MutationObserver 的回调是微任务，适合监听 DOM 变化后做轻量同步更新
• 不要依赖 setTimeout(fn, 0) 实现“next tick”，它本质是宏任务，延迟不可控（可能 >1ms）

写异步逻辑时最容易踩的三个坑

不是记不住宏/微任务分类，而是没意识到它们如何嵌套和累积。

• 在 Promise.then() 里又返回新 Promise，会新增微任务，不是“接着执行”，而是排队等本轮微任务清空后才进队
• await 后面如果是非 Promise 值（如数字、字符串），不会产生微任务，直接同步继续；只有真正 await Promise 才触发暂停+微任务调度
• 用 setTimeout 模拟“等待渲染完成”不靠谱——UI 渲染是宏任务，但时机受帧率、其他任务挤压影响，应改用 requestAnimationFrame() 或 queueMicrotask() + getComputedStyle() 触发重排

真正难的从来不是“哪个先执行”，而是当多个异步链交叉嵌套时，微任务像雪球一样滚出意料之外的执行节奏——这时候别猜，加 console.timeLog() 或用 DevTools 的 **Event Log** 面板看真实调度顺序。