JavaScript事件循环通过微任务队列实现高优先级任务的快速响应，微任务在当前宏任务结束后立即全部执行；宏任务无法提权，需自建优先级队列；滥用微任务会导致事件循环饥饿或布局抖动，应结合渲染节奏（如requestAnimationFrame）精准调度。
javascript 事件循环本身不提供“设置优先级”的 api，但它通过天然的队列分层机制，让开发者能间接实现高优先级任务的快速响应——关键在于把任务放进微任务队列，而不是等待宏任务排队。
微任务是高优任务的默认通道
所有微任务（Promise.then/catch/finally、queueMicrotask、MutationObserver）都会在当前宏任务结束后、下一个宏任务开始前被**全部清空执行**。这个机制不是“加速”，而是“抢占时机”：
- 用户点击后立刻更新状态？用
queueMicrotask(() => { updateUI(); })，确保 DOM 变更同步完成后再运行 - 表单校验失败需即时反馈？在 Promise 链中用
.then处理，比 setTimeout 更早触发 - React 的 setState 批处理、Vue 的 nextTick，底层都依赖这一机制保证视图更新不被延迟
宏任务内部无法提权，必须分层调度
同属宏任务（如多个 setTimeout(0)）严格按注册顺序 FIFO 执行，浏览器不支持插入高优项。若需区分优先级，得自己建队列：
- 维护
highQueue、normalQueue、lowQueue三个数组 - 用
queueMicrotask(checkAndRunHigh)触发一次检查，只从最高非空队列取一个任务执行 - 避免一次性全跑完高优队列，防止饿死其他任务；可加计数或时间切片控制
别把微任务当万能加速器
微任务优先级高，但滥用会引发严重问题：
- 在微任务里反复调用
queueMicrotask或创建新 Promise.then，会导致事件循环饥饿——界面完全卡死，连滚动和点击都无法响应 - 大量 DOM 读写 + 微任务组合，可能触发强制同步布局（layout thrashing），反而拖慢渲染
- 真正耗时操作（如解析大 JSON、图像处理）不能靠微任务提速，它不释放主线程，应移交 Web Worker
结合渲染节奏做精准调度
高优 ≠ 越快越好，而是“在正确时机执行”。例如：
立即学习“Java免费学习笔记（深入）”；
- 需要等 DOM 更新完再测量尺寸？用
queueMicrotask - 需要等浏览器完成绘制再做动画？用
requestAnimationFrame（属于宏任务，但紧邻渲染阶段） - 后台日志上报不影响交互？用
setTimeout(fn, 0)或postMessage模拟低优延后
