事件循环按“同步→微任务（全清）→宏任务（一个）”节拍运转：先执行所有同步代码，再清空微任务队列，最后执行一个宏任务。
JavaScript事件循环不是“等一个任务做完再做下一个”，而是用一套明确的调度规则，让单线程也能高效响应用户、处理网络请求、执行动画，还不卡页面。关键在于它分清了同步代码、微任务、宏任务三类工作，并严格按顺序交接控制权。
事件循环怎么一步步运转
每次循环只做三件事，且顺序固定：
- 先跑完所有当前同步代码（比如函数调用、console.log、变量赋值）
- 同步代码一结束，立刻清空全部微任务（Promise.then、queueMicrotask、MutationObserver回调）——哪怕新微任务在执行中产生，也会被本轮继续处理完
- 微任务队列空了，才从宏任务队列里取一个任务执行（比如setTimeout、setInterval、DOM事件、I/O回调）
这个“同步 → 微任务（全清）→ 宏任务（一个）→ 循环”就是核心节拍。它确保Promise总比setTimeout快，也解释了为什么连续两个setTimeout(0)不会并行执行，而是排队。
异步编程中最容易踩的三个坑
误区不在语法，而在对执行时机的直觉偏差：
立即学习“Java免费学习笔记（深入）”；
- 以为await之后的代码会“紧接着”执行：其实await只是暂停当前async函数，控制权交还给事件循环；后续代码属于微任务，要等当前同步块和已有微任务走完才运行
- 把多个setTimeout(0)当成并行启动：它们都进宏任务队列，按插入顺序一个个执行，中间可能穿插大量微任务和渲染，实际间隔远大于0ms
- 在Promise里写阻塞逻辑，误以为“用了Promise就不卡”：Promise构造器里的代码是同步执行的；如果在里面写死循环或大数组排序，主线程一样冻结，只是then回调会延后
怎么验证你理解对了
看这段代码的实际输出顺序：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4);
结果一定是1 → 4 → 3 → 2。不是靠记忆，而是能说出每一步：1和4是同步；3是微任务，紧接同步后执行；2是宏任务，在微任务清空后才轮到。这种可推导性，才是掌握事件循环的标志。
