事件循环每轮只取一个宏任务，执行完后必须清空全部微任务队列才进入下一轮；同步代码属首个宏任务，故console.log('end')总在Promise.then之前输出。
事件循环怎么调度 Promise 和 setTimeout？
事件循环不是“先执行完所有宏任务再处理微任务”，而是每轮只取一个宏任务，但**必须清空当前全部微任务**后才进入下一轮。这是最常被误解的点。
比如你连续注册 5 个 Promise.then()，它们会一次性全部执行；但 5 个 setTimeout(..., 0) 会分 5 轮依次触发——哪怕时间都设为 0。
- 微任务队列在每次宏任务结束后立即“倾倒”，没有延迟
- 宏任务之间有明确边界：UI 渲染、用户事件、
setTimeout都算独立宏任务 -
queueMicrotask()和Promise.then()行为一致，但前者更语义清晰、无状态开销
为什么 console.log('end') 总比 Promise.then 先输出？
因为同步代码（包括整个 script 标签）本身就是第一个宏任务。它执行完才开始检查微任务队列——所以 console.log('end') 是同步阶段最后一步，而 Promise.then() 是紧接着的微任务阶段第一件事。
console.log('start');
setTimeout(() => console.log('timeout'), 0);
Promise.resolve().then(() => console.log('promise'));
console.log('end');输出顺序固定为：start → end → promise → timeout。这不是“快慢”问题，是**执行阶段不可跳过**：同步 → 微任务 → 下一轮宏任务。
立即学习“Java免费学习笔记（深入）”；
Node.js 和浏览器的事件循环有啥实际差异？
对前端开发者影响最大的是：setImmediate() 和 process.nextTick() 在 Node 中存在，但浏览器里没有；而 MutationObserver 是浏览器特有微任务源。
-
process.nextTick()在 Node 中优先级高于Promise.then()，但它不属于标准事件循环规范，仅限 Node 环境 - 浏览器中
MutationObserver的回调是微任务，适合监听 DOM 变化后做轻量同步更新 - 不要依赖
setTimeout(fn, 0)实现“next tick”，它本质是宏任务，延迟不可控（可能 >1ms）
写异步逻辑时最容易踩的三个坑
不是记不住宏/微任务分类，而是没意识到它们如何嵌套和累积。
- 在
Promise.then()里又返回新Promise，会新增微任务，不是“接着执行”，而是排队等本轮微任务清空后才进队 -
await后面如果是非 Promise 值（如数字、字符串），不会产生微任务，直接同步继续；只有真正 await Promise 才触发暂停+微任务调度 - 用
setTimeout模拟“等待渲染完成”不靠谱——UI 渲染是宏任务，但时机受帧率、其他任务挤压影响，应改用requestAnimationFrame()或queueMicrotask()+getComputedStyle()触发重排
真正难的从来不是“哪个先执行”，而是当多个异步链交叉嵌套时，微任务像雪球一样滚出意料之外的执行节奏——这时候别猜，加 console.timeLog() 或用 DevTools 的 **Event Log** 面板看真实调度顺序。
