JavaScript事件循环通过调用栈、宏任务队列和微任务队列协同实现异步非阻塞，宏任务后必清空微任务队列，故Promise.then总比setTimeout先执行。
JavaScript 事件循环是运行时处理异步操作的核心机制，它决定了代码何时执行、按什么顺序执行。它不是 JavaScript 引擎的“额外功能”，而是单线程模型下实现非阻塞行为的关键设计——没有它，setTimeout、fetch、click 等异步任务就无法在不卡死页面的情况下工作。
事件循环怎么组织任务执行？
JavaScript 运行在单线程环境中，但通过“调用栈 + 任务队列 + 事件循环”协同工作：
- 调用栈：同步代码逐行压入、执行完立即弹出（LIFO）
- 宏任务队列（Macrotask Queue）：存放 setTimeout、setInterval、I/O、UI 渲染 等任务
- 微任务队列（Microtask Queue）：存放 Promise.then/catch/finally、queueMicrotask、MutationObserver 回调
- 事件循环：每次宏任务执行完后，清空整个微任务队列，再取下一个宏任务
为什么 Promise.then 总比 setTimeout 先执行？
因为它们进入不同队列，且事件循环有明确优先级：一个宏任务结束后，必须先执行完所有排队的微任务，才去取下一个宏任务。看这个例子：
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
同步代码 1 和 4 先进栈执行；Promise.then 进入微任务队列；setTimeout 进入宏任务队列；事件循环在第一轮宏任务（脚本本身）结束后，立刻处理微任务（输出 3），之后才轮到第二轮宏任务（输出 2）。
立即学习“Java免费学习笔记（深入）”；
实际开发中容易踩的坑
- 误以为 setTimeout(0) 是“立刻执行”：它只是尽快加入宏任务队列，前面可能还有未处理完的微任务或正在运行的长同步任务
- 在 Promise 链里写大量同步逻辑：虽然不会阻塞 UI，但会拖慢微任务队列，延迟后续宏任务（比如按钮点击响应）
- 用 while(true) 模拟等待：彻底阻塞调用栈，微任务和宏任务全部卡住，页面假死
- 监听 DOM 变化用 setTimeout 而非 MutationObserver：后者属于微任务，响应更快更精准
怎么验证当前执行阶段？
可以借助 queueMicrotask 和 setTimeout 的执行顺序来探测：
queueMicrotask(() => console.log('micro'));
setTimeout(() => console.log('macro'), 0);
// 总是 micro 先于 macro 打印
也可以用 Performance.now() 结合多次测量，观察回调的实际延迟是否符合预期——尤其在网络请求或动画帧场景中，能帮你判断是不是被长任务拖住了。
基本上就这些。事件循环不复杂，但容易忽略它对执行时机的严格约束。理解宏任务与微任务的分离，就能预判异步代码的真实顺序，写出响应及时、不易出错的逻辑。
