事件循环是单线程任务执行节奏：同步代码→清空所有微任务→执行一个宏任务→循环。Promise.then总比setTimeout先执行，因前者属微任务、后者属宏任务，且每轮宏任务后必须立即清空全部微任务。
事件循环不是“多线程调度器”，而是单线程任务执行节奏
JavaScript 事件循环本质是一套严格固定的执行节奏：同步代码 → 清空所有微任务 → 执行一个宏任务 → 再清空所有微任务 → 循环。它不决定“哪个异步操作先发起”，而决定“哪个回调先被执行”。你写的 setTimeout 和 Promise.then 都会进队列，但谁先跑、谁后跑，全由这个节奏控制。
Promise.then 为什么总比 setTimeout 先打印？
因为前者是微任务，后者是宏任务——这是执行顺序差异的根源，不是“Promise 更快”或“setTimeout 更慢”。关键规则只有一条：每个宏任务执行完后，必须立刻、连续、全部执行当前微任务队列里的任务，一个不留。
常见错误现象：
- 以为 setTimeout(() => console.log(2), 0) 会“马上”执行，结果发现它排在 Promise.then 后面；
- 在 then 回调里又写了一个 then，误以为要等下一轮事件循环才执行，其实它仍属于本轮微任务，会立即链式执行完。
实操建议：
- 需要“尽快响应”的逻辑（如状态更新、错误捕获）优先用 Promise.resolve().then() 或 queueMicrotask()；
- 需要“让出主线程、等渲染完成后再做”的操作（如滚动定位、DOM 测量），才用 setTimeout(..., 0) 或 requestAnimationFrame（注意：后者也是宏任务）。
哪些是宏任务？哪些是微任务？别凭感觉记
宏任务和微任务的分类由宿主环境定义，不是语言规范强制的。浏览器和 Node.js 略有不同，但日常开发中可按以下清单对照：
宏任务（每次只取一个执行）：
- 全局脚本（最外层代码）
- setTimeout / setInterval 回调
- postMessage、MessageChannel 消息处理
- UI 渲染（浏览器，非 JS 可控，但会影响时机）
- DOM 事件回调（如 click、input）
微任务（当前宏任务一结束就全清掉）：
- Promise.then/catch/finally 回调（注意：new Promise(() => {...}) 里的函数是同步执行的）
- queueMicrotask()
- MutationObserver 回调
- await 后续代码（本质是 Promise 微任务的语法糖）
调试时怎么验证执行顺序？别靠猜
直接看输出顺序是最可靠的验证方式。例如这段代码：
立即学习“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 进入微任务队列；
- setTimeout 进入宏任务队列；
- 同步脚本结束 → 清微任务 → 打印 3 → 取下一个宏任务 → 打印 2。
容易忽略的关键点：
- 微任务可以无限嵌套（比如在 then 里再 then），它们都会在本轮微任务阶段执行完，不会中断去拿新宏任务；
- 多个 setTimeout 即使延迟都是 0，也严格按注册顺序执行（FIFO），但永远排在所有微任务之后；
- 浏览器的 UI 渲染发生在微任务清空之后、下一个宏任务开始之前——这意味着你在微任务里改 DOM，用户看不到“中间态”，而在宏任务里改，可能触发一次重绘。
