JavaScript事件循环机制:为什么你的代码先执行或后执行?
各位朋友！你有没有过这样的经历：明明代码看起来没毛病，逻辑也对，可运行起来就是“出乎意料”？比如，你设置了一个定时器让它1秒后执行，结果发现另一段看起来在它“后面”的代码反而先跑完了；又或者，你想用网络请求获取数据，结果数据还没回来，后面的代码已经因为缺少数据报错了。是不是瞬间有种“我的代码怎么不听话了？”的抓狂感？这种“不听话”的背后，通常都指向JavaScript里一个非常核心、却又常常被忽视的机制——事件循环（Event Loop）。
别急！今天咱们就来一场JavaScript世界的“幕后大揭秘”。如果把你的JavaScript代码想象成一个厨房里忙碌的厨师（没错，他只有一只手！），那么事件循环就是这个厨房里的“总调度师”，它决定了哪些菜（代码）能上炉子烹饪，哪些菜需要等待，哪些菜又可以插队。理解它，就像给你的代码装上了“顺风耳”和“千里眼”，从此你将彻底告别那些困扰你的异步Bug，让你的JavaScript代码变得“言听计从”，真正按照你的预期运行！
JavaScript的“无奈”：单线程与它的“分身术”
要理解事件循环，我们得先搞清楚JavaScript的“体质”。你知道吗？JavaScript在浏览器中是单线程的。 这意味着什么？简单说，它同一时间只能干一件事。就像你厨房里只有一位厨师，他一次只能切菜，或者炒菜，或者洗碗，不能同时进行。
单线程听起来很“弱”，对吧？那为什么我们打开网页，它还能同时加载图片、播放视频、响应点击、发起网络请求呢？难道不会因为一个耗时的任务，比如加载一张超大图片，就让整个页面卡死，连按钮都点不动了？
这正是JavaScript的“无奈”与“高明”之处！为了解决单线程带来的“阻塞”问题，JavaScript引擎（比如Chrome的V8引擎）和浏览器环境（或者Node.js运行时）巧妙地配合，玩了一手“分身术”——它将一些耗时操作（比如网络请求、定时器、DOM事件监听等）“外包”出去了！ 当你发起一个网络请求，JS引擎不会傻傻地等在那里直到数据回来，而是会把这个任务交给浏览器（Web API），然后自己继续执行后面的代码。当任务完成时，浏览器会通知JS引擎：我办完啦！
这就像，你让厨师去烤一个蛋糕（耗时任务），厨师把蛋糕推进烤箱（Web API），然后他就可以继续炒别的菜了。烤箱烤好了，会响铃（通知JS引擎），厨师再去处理。
厨房里的“三大件”与“调度师”
要让这种“外包”和“通知”机制流畅运转，JavaScript的运行时环境里有几个关键的“基础设施”：
- 调用栈（Call Stack）： 这就是我们厨师的“主工作台”。所有同步（立刻执行的）代码，以及函数调用，都会被压入这个栈中，遵循“后进先出”的原则。只有栈顶的函数才能被执行。当一个函数执行完毕，它就会从栈中弹出。
- Web APIs (或 Node APIs)： 这就是我们厨房里的“烤箱”、“洗碗机”、“高压锅”等专用电器。像setTimeout、setInterval、fetch、DOM事件监听（addEventListener）等这些异步操作，它们并不是JavaScript引擎本身负责执行的，而是由浏览器或Node.js环境提供的特殊能力。当JS代码调用它们时，任务就会被“扔”给这些Web APIs去处理。
- 任务队列（Task Queue / Callback Queue）： 这就像我们厨房里的一个“叫号系统”或者“待取餐区”。当Web API完成了它负责的异步任务后，如果这个任务有回调函数（也就是我们交给它的“当任务完成时你要执行的代码”），这个回调函数并不会立即回到调用栈执行，而是会被放到这个“任务队列”里排队。
- 微任务队列（Microtask Queue）： 这是一个比普通任务队列优先级更高的“VIP等待区”。主要用于处理Promise的回调（.then().catch().finally()）和MutationObserver的回调。它们比普通任务队列里的任务插队！
- 事件循环（Event Loop）： 终于轮到我们的“总调度师”了！它就像厨房里那位眼观六路、耳听八方的经理。它的职责非常简单，但至关重要：不断地检查调用栈是否为空。如果调用栈空了（意味着主工作台上的厨师忙完了，暂时没活干了），它就会去检查“微任务队列”里有没有任务。如果有，它会一口气把微任务队列里所有任务都搬到调用栈去执行，直到微任务队列清空。微任务队列清空后，它才会去检查“普通任务队列”，从里面取出第一个任务的回调函数，放到调用栈去执行。这个过程周而复始，永不停歇。
跑得快的秘密：一次完整的“调度”流程
现在，我们把所有概念串起来，看看你的JavaScript代码是如何在事件循环的调度下运行的：
- 初始执行： 当你的JavaScript代码开始执行时，所有的同步代码会被第一时间推入调用栈并立即执行。
- 异步“外包”： 如果遇到setTimeout、fetch或事件监听等异步操作，JS引擎会把它们交给Web API去处理，然后自己立刻执行调用栈中的下一行代码，不会等待。
- 任务“入队”： Web API在后台默默地执行它的任务。当任务完成时（比如定时器时间到了，或者网络请求数据回来了），Web API会将对应的回调函数推入任务队列或微任务队列。
- 循环等待： 事件循环一直在旁边“虎视眈眈”。它的核心工作就是等待。
- 优先微任务： 一旦调用栈清空（所有同步代码都执行完了），事件循环会立刻检查微任务队列。如果微任务队列里有任务，它会把它们全部移到调用栈中执行，直到微任务队列彻底清空。
- 再看普通任务： 只有当微任务队列也清空后，事件循环才会去普通任务队列中，取出第一个等待的回调函数，将其推入调用栈执行。
- 周而复始： 当这个回调函数执行完毕并从调用栈中弹出后，事件循环会再次检查调用栈是否为空（它当然是空的），然后重复步骤5和6。
所以，想象一下：主厨（调用栈）在炒菜。他让烤箱（Web API）烤面包，面包好了响铃，把“取面包”这个任务放入叫号系统（任务队列）。同时，主厨又接了一个“加急订单”（Promise），这个加急订单好了，通知直接进入“VIP取餐区”（微任务队列）。当主厨主菜炒完空下来时，他会先看VIP取餐区有没有加急订单，把所有加急订单都做了，再去看叫号系统，按顺序处理普通任务。
为什么你的代码会“不听话”？——常见异步Bug剖析
理解了事件循环的流程，很多以前让你困惑的现象就迎刃而解了：
- setTimeout(fn, 0) 并不立即执行： 你可能会想，setTimeout(fn, 0) 意味着立即执行对吧？错！它依然是一个异步任务，只是等待时间为0。它会被Web API处理，然后把回调函数放到普通任务队列里排队。只有当所有同步代码执行完毕，并且所有微任务也执行完毕后，它才能被事件循环选中并执行。所以，console.log('1'); setTimeout(() => console.log('2'), 0); console.log('3'); 的输出顺序永远是 1 -> 3 -> 2。
- Promise比setTimeout先执行： 这就是微任务队列的功劳！Promise的回调（.then()）是微任务，而setTimeout的回调是普通任务。当调用栈清空时，事件循环会优先清空所有微任务，然后才会处理普通任务。
console.log('Start'); // 同步任务
setTimeout(() => {
console.log('setTimeout'); // 普通任务
}, 0);
Promise.resolve().then(() => {
console.log('Promise resolved'); // 微任务
});
console.log('End'); // 同步任务
// 实际输出顺序：
// Start
// End
// Promise resolved
// setTimeout
- 长耗时同步代码会“卡死”页面： 如果你的调用栈里有一个非常耗时（比如计算量巨大、无限循环）的同步任务，那么在它执行完成并从调用栈弹出之前，事件循环根本就没有机会去检查任务队列和微任务队列！页面上的任何交互（点击、滚动）都无法响应，定时器也无法按时触发，因为厨师被一个任务完全“堵死”了，没空理会其他事情。
掌握事件循环，告别Bug困扰！
理解事件循环，是掌握JavaScript异步编程的关键。它不仅仅是概念，更是你解决实际问题，优化前端性能，避免各种“玄学Bug”的利器。
给你的几点建议：
- 警惕“同步”阻塞： 避免在主线程（同步代码）中进行长时间的计算或密集操作。如果确实有这种需求，考虑使用Web Workers将其放到后台线程处理，或者将任务拆分成小块，在多个事件循环周期中分步执行。
- 分清“宏任务”与“微任务”： 记住Promise回调是微任务，它的优先级高于setTimeout和DOM事件回调这些宏任务。这能帮你预测代码的执行顺序。
- 善用async/await： 虽然async/await是Promise的语法糖，但它让异步代码看起来更像同步代码，大大提高了可读性。理解其背后依然是事件循环在调度，能让你更放心地使用它们。
- 调试工具是你的眼： 利用Chrome DevTools的“Performance”面板，你可以清晰地看到调用栈、任务队列的执行情况，哪些任务耗时，哪些阻塞了主线程，一目了然！
JavaScript的事件循环就像一个精密运转的齿轮系统，它让单线程的JavaScript能够处理复杂的异步任务，赋予了它强大的生命力。一旦你真正理解了它，那些曾经让你头疼的“代码为什么不听话”的问题，都将迎刃而解。你将不再是被动的观察者，而是能主动驾驭异步，写出更高效、更健壮、更可靠的JavaScript代码。
你曾经被哪个异步Bug困扰过？或者对事件循环还有哪些好奇？欢迎在评论区分享你的故事和疑问，咱们一起探索JavaScript的更多奥秘！
