应控制微任务数量与执行时机以避免主线程阻塞。具体包括：分片处理、避免无条件递归、合理选用宏任务与 requestidlecallback、监控隐式微任务、优先使用 queuemicrotask。
大量微任务会阻塞主线程，导致界面卡顿、输入无响应、渲染延迟。关键不是“怎么执行更多”，而是“如何不让它们挤在一起”。
控制单次微任务的处理量
避免一次性调度成百上千个微任务。用分片（chunking）把大任务切小：
- 每次只处理 50–100 条数据，处理完再用 queueMicrotask 调度下一批
- 不要在 Promise.then 中无条件递归调用自身，改用带退出条件的循环 + 微任务分发
- 示例：批量更新状态时，检查是否已达到阈值或用户交互中断信号，及时暂停
该用宏任务时别硬塞微任务
微任务适合“立刻但不打断渲染”的逻辑，不是万能加速器：
- 耗时计算、大批量 DOM 操作、图片解码等——移交 Web Worker 或改用 setTimeout(fn, 0)
- 滚动/输入中高频触发的更新，优先考虑 requestIdleCallback，让浏览器决定空闲时机执行
- 需要保证渲染可见性的操作（如动画帧后读取 layout），用 requestAnimationFrame + 微任务组合
监控和拦截隐式微任务
第三方库（如某些响应式框架、表单校验工具）可能悄悄产生大量微任务：
- 打开 Chrome DevTools → Performance 面板 → 录制交互，筛选 microtask 查看数量与耗时占比
- 若单轮微任务总耗时超 5ms 或数量超 200 个，说明存在风险
- 对可疑模块做包裹隔离，例如用 setTimeout 包一层再触发其更新逻辑，主动让出本轮微任务队列
用 queueMicrotask 替代 Promise.then 做轻量调度
减少不必要的开销，提升可控性：
- queueMicrotask 不创建 Promise 实例，无链式能力，语义清晰，是标准推荐方式
- 旧环境可用 polyfill：queueMicrotask || (fn => Promise.resolve().then(fn))
- 避免混用：同一逻辑中不要既用 Promise.then 又用 queueMicrotask，防止执行顺序难预测
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
