事件循环是单线程JavaScript中实现异步任务调度的核心机制，通过宏任务队列（如setTimeout）和微任务队列（如Promise.then）的交替执行来模拟并发。
事件循环本质是单线程下的“任务调度器”
JavaScript 是单线程的，不能同时执行两段代码；但又要响应点击、定时器、网络请求等异步操作——事件循环就是解决这个矛盾的核心机制。它不“并发”，而是靠排队+切换来模拟异步：同步代码走完，立刻检查有没有微任务要跑；微任务清空后，再取下一个宏任务。
setTimeout 是宏任务，Promise.then 是微任务，这是最稳的区分依据
区分宏任务和微任务，别记定义，直接看“谁往哪个队列塞任务”。浏览器/Node.js 引擎内部有两套独立队列：macrotask queue 和 microtask queue。你调用的 API 决定了它进哪边：
-
setTimeout、setInterval、UI 渲染、script整体、fetch回调（完成时）、click事件处理器 → 全进宏任务队列 -
Promise.then/.catch/.finally、queueMicrotask、MutationObserver回调 → 全进微任务队列 - Node.js 中
process.nextTick也属微任务，但优先级比Promise还高（仅限 Node）
哪怕 setTimeout(() => {}, 0) 延迟为 0，它仍是宏任务，一定排在当前所有微任务之后执行。
为什么 console.log 顺序总和预期不一样？
因为你在写代码时默认按“书写顺序”脑补执行流，但事件循环会把异步部分“挪走排队”。下面这段代码能暴露全部逻辑：
立即学习“Java免费学习笔记（深入）”；
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是微任务，当前宏任务（即整个脚本）结束后立刻执行 → 输出3 -
setTimeout是宏任务，得等上一轮事件循环彻底结束（包括微任务清空），才轮到它 → 输出2
这种“延迟不可控”的现象，不是 bug，是机制使然。想强制某段逻辑在渲染前执行，就用微任务；想等页面更新后再做处理，就得用 setTimeout 或 requestIdleCallback。
容易被忽略的关键细节
微任务不是“马上执行”，而是“当前宏任务末尾立即执行”——这意味着：
- 一个微任务里再抛出
Promise.then，它会加入**同一轮微任务队列末尾**，而不是立刻执行（所以能形成链式清空） - 微任务队列是“一次性清空”的：哪怕你连续 10 次
queueMicrotask，它们都会在当前宏任务结束后按顺序跑完，中间不会穿插任何宏任务或渲染 - 浏览器会在每轮宏任务 + 微任务完成后，**主动触发一次 UI 渲染**（如果 DOM 有变化）。所以如果你在微任务里疯狂改 DOM，用户看不到中间态；而放在
setTimeout里，就能看到逐帧效果
真正难调试的，往往不是“哪个先执行”，而是“为什么我的 Promise 回调没拿到最新 DOM 状态”——答案通常是：你忘了微任务发生在渲染前，而你想读的是渲染后的布局信息。
