javascript事件循环中微任务优先级高于宏任务，每次宏任务执行完立即清空微任务队列；promise.then、queuemicrotask等属微任务，settimeout、ui渲染等属宏任务；合理使用可优化渲染与状态更新，但滥用会导致事件循环饥饿。
JavaScript 通过事件循环（Event Loop）协调同步代码、宏任务（macrotask）和微任务（microtask），从而隐式实现任务优先级——微任务总在当前宏任务结束前执行，优先级高于宏任务。
宏任务与微任务的层级关系
事件循环每次只处理一个宏任务（如 setTimeout 回调、setInterval、I/O、UI 渲染），但会在该宏任务执行完毕后、下一个宏任务开始前，**清空整个微任务队列**。这意味着：
- Promise.then/catch/finally、queueMicrotask、MutationObserver 回调属于微任务，立即执行且不被中断
- setTimeout/setInterval、script 初始化、postMessage、UI 渲染属于宏任务，排队等待下一轮循环
- 一个微任务中添加的新微任务，也会在本轮末尾执行（队列追加），不会等到下一轮
用微任务抢占执行时机
当需要比 setTimeout 更快响应、又不想阻塞主线程时，可用微任务模拟“高优调度”。例如：
- 避免渲染抖动：用 queueMicrotask 替代 setTimeout(fn, 0)，确保在 DOM 更新后、下次绘制前运行
- 批量更新优化：将多个状态变更收拢到一次微任务中，防止重复 render（React 的 setState 批处理底层就依赖此机制）
- 错误边界兜底：在 Promise 链异常后，用 queueMicrotask(() => { /* 清理或降级 */ }) 确保及时响应，不被后续宏任务延迟
注意嵌套与性能陷阱
微任务虽优先级高，但滥用会导致事件循环饥饿（starvation）：
- 在微任务中不断 queueMicrotask 或触发新的 Promise.then，会阻止宏任务执行，界面卡死
- 大量 DOM 变更 + 微任务组合可能引发强制同步布局（layout thrashing），应结合 requestAnimationFrame 控制渲染节奏
- 不要用微任务替代真正的异步逻辑（如网络请求），它不释放线程，只是调整执行顺序
实际调度策略建议
按意图选择任务类型，而非盲目追求“更快”：
- 需保证 DOM 已更新 → 用 queueMicrotask
- 需等待浏览器完成渲染（如测量尺寸）→ 用 requestAnimationFrame（属于宏任务，但紧邻渲染）
- 需延后到下一个空闲周期 → 用 requestIdleCallback（非标准但广泛支持）
- 真正耗时操作 → 移出主线程（Web Worker）或分片（time slicing）+ 宏任务切片
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
