JavaScript事件循环是协调同步与异步代码执行的核心调度机制，通过宏任务与微任务队列的优先级调度，实现单线程下的非阻塞响应，确保页面不卡顿。
JavaScript事件循环是协调同步与异步代码执行的核心调度机制。它让单线程的JS能在不卡住页面的前提下，有序处理定时器、网络请求、用户点击等异步任务。
事件循环解决的根本问题
JavaScript天生单线程，意味着同一时刻只能做一件事。如果所有操作都必须等前一个完成，一次3秒的API请求就会让整个页面冻结——按钮点不了、滚动卡住、动画停摆。事件循环通过“先干完手头事，再回头处理异步结果”的方式，把阻塞式等待变成非阻塞式响应。
- 同步代码（如
console.log、函数调用）直接进调用栈，立刻执行 - 异步操作（如
setTimeout、fetch、Promise）交由浏览器后台线程处理，不占主线程 - 结果就绪后，回调被分类放入宏任务队列或微任务队列，等调用栈空了再执行
宏任务和微任务的执行顺序很关键
不是所有异步任务“一视同仁”。事件循环每次只从宏任务队列取一个任务（比如setTimeout回调），但会在每个宏任务执行完毕后，清空当前所有的微任务（比如Promise.then、queueMicrotask）。这个优先级差异直接影响代码行为。
- 宏任务：整体脚本、
setTimeout、setInterval、I/O、UI渲染 - 微任务：
Promise链、MutationObserver、queueMicrotask - 典型输出顺序：
console.log('1')→console.log('4')→Promise.then→setTimeout回调
不理解事件循环容易踩的实际坑
很多看似“理所当然”的代码行为，其实背后全靠事件循环兜底。忽略它，轻则逻辑错乱，重则性能崩溃。
立即学习“Java免费学习笔记（深入）”；
-
状态更新丢失：连续多次
setState（React）或ref.value = ...（Vue）可能被合并，因为它们依赖微任务队列的批量处理 -
DOM操作时机错误：在
Promise.then里读取刚修改的DOM，能拿到最新值；但在setTimeout里可能读不到，因为UI渲染发生在宏任务之间 -
无限微任务风险：在
Promise.then里又创建新Promise并then自己，会持续抢占主线程，导致页面假死
它是现代前端开发的底层共识
从async/await到useEffect，从requestIdleCallback到Web Workers通信，几乎所有异步抽象都建立在事件循环之上。框架源码、性能调试工具（如Chrome DevTools的Event Loop面板）、甚至Node.js的process.nextTick与setImmediate的区别，都需要事件循环视角才能真正看懂。
