如果说异步编程告诉你“结果不会立刻回来”，那事件循环回答的就是“它到底什么时候回来，以及先后顺序为什么是这样”。很多 JavaScript 的经典困惑都集中在这里：为什么 setTimeout(fn, 0) 不是立刻执行，为什么 Promise 的回调看起来总比定时器更早，为什么页面会卡顿，为什么一段代码明明不复杂却能明显阻塞交互。
这一篇不是为了把你训练成“手写输出顺序题机器”，而是要建立一个对真实项目有用的调度心智。你要知道主线程在做什么、宏任务和微任务有什么区别、浏览器渲染大概插在什么位置、长任务为什么会影响用户体验。只要这套图景清楚，很多异步和性能问题都会更可解释。
先建立最基本的图景
JavaScript 主线执行时，会先运行当前调用栈中的同步代码。同步代码执行完后，运行时会查看任务队列，把待执行任务按规则推进。这个“不断检查、不断执行”的循环过程，就是事件循环。
关键在于，所有异步操作并不是凭空自己执行，而是先由浏览器或 Node 等宿主环境处理，等条件满足后再把后续逻辑放入合适的任务队列，等待主线程空出来再执行。
宏任务和微任务，为什么要分两种？
因为不同类型的异步回调需要不同优先级。一个非常粗略但有用的理解是：
- 宏任务通常代表一轮较大的事件来源，例如定时器回调、I/O 回调、用户事件等；
- 微任务通常用于更细粒度地衔接当前逻辑之后的后续操作，例如 Promise 的后续处理。
运行时通常会在一轮宏任务结束后，先把当前积压的微任务清空，再进入下一轮更大的任务调度。正因为如此，Promise 回调常常会先于很多定时器逻辑执行。
你不一定要死记所有分类细节，但一定要建立一个意识：不是所有异步任务优先级都一样，Promise 和定时器之所以表现不同，是有调度规则支撑的。
setTimeout(fn, 0) 为什么不是“立即执行”？
这是事件循环最经典的误区之一。0 只意味着“最短延迟达到后就可以被放入队列等待调度”，不是“打断当前同步代码马上执行”。如果主线程还在忙、调用栈没空、前面还有更高优先级的微任务，那么这个回调仍然得排队。
项目里很多人拿 setTimeout(..., 0) 当成“强行异步”“延后一下”的万能钥匙，其实并不总稳。你需要知道它只是把逻辑放到更后的一轮任务里，而不是精准控制执行时机。
真实项目里哪些时序问题最常把人绕进去？
很典型的几类包括：事件回调里先改状态再读 DOM，结果拿到的还是旧信息；Promise 回调和定时器都在参与同一段流程时，执行顺序和预想不同；某个异步请求回来时，页面状态已经不是发请求那一刻的上下文了。它们看起来像三种问题，本质上都和任务调度时机有关。
也正因为如此，事件循环学习真正的价值，不在于答面试题，而在于你遇到时序 bug 时不再完全靠猜。
Promise 为什么经常“比你想的更早”？
因为 Promise 的后续处理通常进入微任务队列，而微任务会在当前宏任务末尾优先清空。于是你经常会看到这样的现象：同步代码先执行，接着 Promise 回调执行，然后才轮到定时器。这个规律如果不理解，很多时序判断就会出错。
这也是为什么前一篇强调：async/await 只是语法更接近同步，底层仍然在参与微任务调度。如果你不了解这一层，就容易在状态更新、界面刷新和错误处理时做出错误预期。
浏览器渲染为什么有时会让你感觉“顺序不讲道理”？
因为开发者眼里看到的是代码顺序，浏览器眼里处理的是调用栈、任务队列和渲染时机。你以为“这一句改完了页面应该马上变”，但浏览器可能还在等当前任务清空、微任务处理完、再进入下一轮渲染节奏。只要不把渲染也放进这张图里，很多 UI 时序现象都会显得很玄。
浏览器渲染和事件循环有什么关系？
这对前端开发特别重要。页面渲染不是在你每修改一次 DOM 后立刻发生，而是和浏览器的调度节奏、样式计算、布局、绘制等步骤有关。如果主线程持续被长时间同步任务占住，浏览器就没法及时响应输入和完成渲染，用户就会感到卡顿。
这意味着，性能问题并不总是“算法太慢”，也可能是你把太多工作塞进了不合适的时机。比如频繁操作 DOM、滚动事件里做大量计算、一次性处理庞大数据，都可能让主线程长时间无法让出控制权。
长任务为什么危险？
所谓长任务，本质上是主线程连续忙碌太久，导致用户输入响应、动画帧、页面渲染和后续任务都被拖慢。对用户来说，他们不关心你代码里有没有复杂循环，只关心按钮点下去为什么没反应。
所以项目里你要形成一个习惯：只要逻辑可能比较重，就思考能否拆分、延后、异步化、放到 Worker，或者减少不必要的同步处理。事件循环的学习价值，不在于背题，而在于你开始具备“时机意识”。
排查异步时序问题时，最稳的思路是什么？
通常是先把整条链拆出来看：哪一段是同步执行，哪一段进入了微任务，哪一段依赖宿主环境回调，哪一段又会触发渲染或用户可见变化。只要先把链路画清楚，很多“为什么这个先发生”“为什么这里读到旧值”的问题都会更容易定位。
常见误区
这一章高频误区包括：
- 把异步任务理解成“谁先写谁先执行”；
- 把
setTimeout(..., 0)当成立即执行； - 以为
await就是同步阻塞； - 忽略微任务优先级，导致状态更新顺序判断错误；
- 只看逻辑正确与否，不看主线程是否被长任务占满。
和后续章节的关系
接下来我们会进入 DOM 与事件系统、网络请求和浏览器性能。无论是事件冒泡、界面更新还是请求回调，它们的行为都和事件循环密切相关。也就是说，这一章是浏览器协作篇的基础解释器。
写在最后
事件循环不是用来制造“JavaScript 很神秘”这种印象的，它恰恰是让 JavaScript 变得可解释的关键。只要你把同步执行、宏任务、微任务、浏览器渲染和主线程负载放进同一张图里看，很多本来像玄学的问题，都会变得非常具体。下一篇我们就进入这张图里的另一个核心部分：DOM 与事件系统。