宏任务和微任务执行误区源于混淆“谁先排队”与“谁先执行”：setTimeout(fn,0)属宏任务，必在当前宏任务及所有微任务后执行；微任务无限嵌套会阻塞主线程；浏览器渲染绑定宏任务末尾；Node.js与浏览器事件循环机制不同，process.nextTick优先级高于Promise。
宏任务和微任务的执行误区，本质是混淆了“谁先排队”和“谁先执行”的关系。很多问题不是代码写错了，而是对事件循环阶段的理解偏差导致的——比如以为 setTimeout(fn, 0) 会立刻执行，或误判 Promise.then 的触发时机。
误区一：认为“0毫秒定时器”比 Promise 快
这是最典型错误。实际上，setTimeout 是宏任务，哪怕延迟为 0，也必须等当前宏任务（如整个 script）执行完、所有微任务清空后才轮到它。
- 同步代码 → 微任务（Promise.then 等）→ 渲染（浏览器）→ 下一个宏任务（包括 setTimeout 回调）
-
Promise.resolve().then(() => console.log('A'))一定在setTimeout(() => console.log('B'), 0)之前输出 - 若想模拟“尽可能快的异步”，应优先用
queueMicrotask，而非降级为setTimeout(..., 0)
误区二：在微任务中无限添加新微任务
微任务队列会在当前宏任务结束后被完全清空，但如果在 then 或 queueMicrotask 回调里又加新的微任务，就会形成递归执行，阻塞后续宏任务甚至导致页面无响应。
- 例如：
Promise.resolve().then(() => queueMicrotask(() => {...}))若不设退出条件，会持续抢占主线程 - 规避方法：加计数限制、用布尔开关控制、或改用
setTimeout切片处理（适合大量数据分批） - Node.js 中尤其注意
process.nextTick，它的优先级比 Promise 还高，滥用更容易卡死
误区三：忽略浏览器渲染时机与宏任务的绑定
UI 渲染不是独立任务，而是在某些宏任务执行完毕后由浏览器自动触发（如 script 结束、事件回调结束、requestAnimationFrame 回调后）。如果把大量 DOM 操作塞进一个宏任务，用户会感知卡顿；但若误拆成过多微任务，又可能因跳过渲染导致视觉闪烁或布局错乱。
- 高频操作（如输入框实时校验）适合用微任务聚合变更，再一次性更新 DOM
- 耗时计算 + DOM 更新组合，建议用
setTimeout或requestAnimationFrame分离，确保中间能渲染 -
MutationObserver是微任务，适合监听 DOM 变化后做轻量响应，但不要在里面做重绘或复杂计算
误区四：混用 Node.js 和浏览器的执行差异
Node.js 的事件循环有多个阶段（Timers、Poll、Check 等），且 process.nextTick 在每个阶段切换前执行，优先级高于 Promise；而浏览器没有这些阶段，只按“宏→微→渲染→宏”线性推进。
- 同一段代码在浏览器和 Node.js 中输出顺序可能不同，比如
setImmediate和setTimeout(..., 0)在 Node.js 中谁先谁后不绝对 - 跨环境代码（如 SSR 或工具库）应避免依赖
process.nextTick，统一用queueMicrotask更安全 - 调试时务必确认运行环境，别拿浏览器的执行逻辑去猜 Node.js 行为
