JavaScript事件循环是异步非阻塞执行的核心机制，通过调用栈、任务队列协作：同步代码入栈执行，异步回调由Web API处理后进入任务队列；事件循环在调用栈空时，先清空所有微任务（如Promise.then），再取一个宏任务（如setTimeout）执行。
JavaScript 中的事件循环（Event Loop）是它实现异步非阻塞执行的核心机制，决定了代码何时执行、按什么顺序执行——尤其是当遇到 setTimeout、Promise、用户点击、网络请求等异步操作时。
调用栈、任务队列和事件循环三者如何协作
JavaScript 是单线程语言，只有一个调用栈（Call Stack）。同步代码立即入栈执行；而异步回调不会立刻运行，而是被交给浏览器或 Node.js 的 Web API（如定时器、fetch）处理。等这些 API 完成后，会把对应的回调函数推入「任务队列」（Task Queue）。事件循环持续监听：只要调用栈为空，就从任务队列中取出一个回调，压入调用栈执行。
- 宏任务（Macrotask）：如
setTimeout、setInterval、I/O、UI 渲染，每次事件循环只处理一个 - 微任务（Microtask）：如
Promise.then、MutationObserver、queueMicrotask，会在当前宏任务结束后、下一个宏任务开始前，全部清空
为什么 Promise.then 总比 setTimeout 先执行
因为 Promise.then 的回调属于微任务，setTimeout 属于宏任务。即使 setTimeout(fn, 0) 设为 0 毫秒，它也要等当前宏任务（比如整个脚本）执行完、所有微任务跑完之后，才轮到它。
例如：
立即学习“Java免费学习笔记（深入）”；
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）。
实际开发中容易踩的坑
- 误以为
setTimeout(fn, 0)能“立刻”执行，其实它至少要等一轮事件循环 - 在大量
Promise.then链中做耗时计算，会阻塞后续微任务甚至 UI 渲染（微任务不中断） - 用
async/await写逻辑时，await后面的代码会被包装成微任务，不是同步延续
基本上就这些。理解事件循环不是为了背概念，而是能预判异步代码的执行节奏，写出更可靠、响应更快的程序。
