事件循环先执行同步代码，再清空微任务队列，最后执行宏任务；因此setTimeout（宏任务）总在Promise.then（微任务）之后执行。
JavaScript 事件循环怎么决定 setTimeout 和 Promise.then 谁先执行？
事件循环不是“先到先执行”的队列，而是分层调度：宏任务（macro-task）和微任务（micro-task）各自排队，且每次宏任务执行完后，**必须清空当前所有微任务队列**，再取下一个宏任务。
典型宏任务包括：setTimeout、setInterval、I/O、UI 渲染；典型微任务包括：Promise.then/catch/finally、MutationObserver、queueMicrotask。
这意味着哪怕 setTimeout(fn, 0) 看似“立刻”，它也得等当前同步代码 + 所有已入队微任务执行完才轮到。
console.log(1); setTimeout(() => console.log(2), 0); Promise.resolve().then(() => console.log(3)); console.log(4); // 输出：1 → 4 → 3 → 2
为什么 async/await 会改变异步流程的“断点”位置？
await 不是阻塞，而是语法糖，底层仍靠 Promise 和微任务实现。每次 await 后的表达式求值完成后，后续代码会被包装进一个新的微任务中。
立即学习“Java免费学习笔记（深入）”；
这导致 await 后的语句不会紧接在上一个同步语句之后执行，而要等本轮微任务清空后才进队——容易误判执行时序。
- 同一函数内多个
await，它们之间是微任务链，不是同步连续 -
await Promise.resolve()等价于Promise.resolve().then(...)，不产生新宏任务 - 如果
await的是普通值（如await 42），会立即转为Promise.resolve(42)，仍走微任务
async function f() {
console.log('a');
await console.log('b'); // 'b' 是同步执行的，但 await 后的 'c' 是微任务
console.log('c');
}
f();
console.log('d');
// 输出：a → b → d → c
Node.js 和浏览器的事件循环阶段有啥关键差异？
浏览器事件循环规范（HTML Standard）定义了 6 个阶段；Node.js（libuv）则明确划分 6 个阶段，其中 timers、pending callbacks、idle/prepare、poll、check、close callbacks，且每个阶段结束后都会检查并执行微任务。
关键区别在于：setImmediate（Node.js 特有）属于 check 阶段，在 poll 阶段空闲后立即触发；而 setTimeout(fn, 0) 属于 timers 阶段，可能被系统延迟干扰；两者谁先执行不绝对，取决于进入 poll 阶段时是否有 I/O 事件待处理。
- 在空
poll阶段，setImmediate总在下一轮循环的check阶段执行，setTimeout可能被提前或延后 - 浏览器没有
setImmediate，也不暴露阶段控制，只保证宏/微任务分离 -
process.nextTick（Node.js）比所有微任务更早执行，甚至在Promise.then前，但它不属于标准事件循环，是 Node.js 特殊钩子
哪些操作看似同步、实则触发微任务，容易引发意外交互？
有些 API 表面无异步痕迹，但内部依赖 Promise 或调度机制，实际把回调推入微任务队列，导致执行时机晚于预期。
-
queueMicrotask(callback)：显式插入微任务，比Promise.then更轻量，无 Promise 构造开销 -
Observable（RxJS）默认使用Promise.then调度，observeOn(asyncScheduler)才切到宏任务 - Vue 3 的
nextTick在浏览器中优先用Promise.then，降级用queueMicrotask或setTimeout - React 的
useEffect回调在渲染提交后以微任务方式调度（v18+ concurrent 模式下可能被中断或延迟）
真正难调试的，往往是那些没写 async、没见 then，却因框架封装悄悄进了微任务的代码——它们打断了你对“同步执行流”的直觉判断。
