事件循环协调调用栈、宏任务队列和微任务队列，确保异步非阻塞：每轮仅执行一个宏任务，但清空全部微任务；Promise.then属微任务，setTimeout属宏任务，故前者总先执行。
JavaScript 的事件循环（Event Loop）是它实现异步非阻塞行为的核心机制。它不负责执行代码，而是协调调用栈（Call Stack）、任务队列（Task Queue，也叫宏任务队列）和微任务队列（Microtask Queue）之间的协作，确保代码既响应及时又不卡住主线程。
调用栈空了，才轮到事件循环干活
JS 是单线程的，所有同步代码都在调用栈里顺序执行。一旦栈清空，事件循环立刻检查：有没有微任务？有就一个个执行完，中间不插队；微任务清空后，再取一个宏任务（比如 setTimeout 回调、用户点击事件）推入调用栈执行。
- 微任务包括：Promise.then/catch/finally、queueMicrotask()、MutationObserver 回调
- 宏任务包括：setTimeout、setInterval、I/O、UI 渲染、postMessage
- 每次“一轮循环”只处理一个宏任务，但会清空当次全部微任务
为什么 Promise.then 总比 setTimeout 先执行？
因为 Promise 回调属于微任务，setTimeout 属于宏任务。即使 setTimeout 设为 0ms，它也要等当前宏任务结束 + 所有微任务跑完，才能排队等待下一轮循环。
例如：
立即学习“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）。
渲染和事件循环的关系很紧密
浏览器会在每个宏任务执行完后，尝试进行一次 UI 渲染（重排、重绘）。但如果你在单个宏任务里做了大量同步计算（比如长循环），渲染就会被卡住——因为事件循环没机会进入“检查是否需要渲染”的阶段。
- 想让页面保持响应，别把耗时操作塞进一个函数里硬算
- 可用 setTimeout(fn, 0) 或 queueMicrotask() 拆分任务，给渲染留出时机
- requestAnimationFrame 是一种特殊的宏任务，专为动画优化，优先级高于普通 setTimeout
async/await 本质还是微任务链
async 函数返回 Promise，await 后面的表达式一旦 resolve，后续代码会被包装成微任务。所以多个 await 并不会创建新宏任务，它们串在同一个微任务流里，仍比下一个 setTimeout 快。
理解这点能帮你预判复杂异步逻辑的执行节奏，避免误以为 “await 等待 = 阻塞整个线程”。
基本上就这些。事件循环不是黑箱，它规则简单、可预测——关键在于分清宏任务和微任务，以及它们触发的时机。写异步代码时多想想“这段回调会进哪个队列”，很多看似奇怪的执行顺序就自然明白了。
