微任务适合逻辑同步但不保证立即渲染，宏任务可控可感知；微任务用于链式状态收敛，宏任务实现视觉过渡；滥用微任务致渲染饥饿，requestAnimationFrame比setTimeout更精准。
状态更新的时机决定渲染效果
宏任务和微任务在状态更新中的核心差异，是它们触发 DOM 变更后是否能被浏览器“看到”并立即渲染。微任务更新的状态，在当前宏任务结束后、下一个宏任务开始前就已完成，但浏览器不会在此时强制重绘；而 UI 渲染本身是一个宏任务，通常发生在微任务队列清空之后、下一个宏任务执行之前（或由 requestAnimationFrame 显式控制）。这意味着：微任务适合做“逻辑上立即生效”的状态同步，但不保证用户立刻看到；宏任务更适合安排“可被观测到的视觉反馈”。
用微任务做状态收敛与链式响应
当多个异步操作需按顺序更新同一状态，且中间步骤不应暴露给 UI 时，微任务天然适合。比如 Promise 链中连续调用 setState（React）或直接修改响应式数据（Vue），所有回调都在微任务队列中串行执行，最终只触发一次视图更新（依赖框架的批量更新机制）。又如使用 queueMicrotask 延迟执行状态归一化逻辑：
- 在事件处理器中快速设置 loading = true
- 立即发起 fetch，返回 Promise
- 用 .then() 更新 data 和 loading = false —— 这些都进微任务队列
- 整个过程无中间渲染，用户要么看到加载态，要么看到完整数据
用宏任务控制可感知的交互节奏
需要让用户明确感知状态变化时，宏任务更可控。例如点击按钮后先显示“处理中”，再模拟耗时操作，最后显示结果——若全用微任务，浏览器可能跳过中间态；改用 setTimeout(..., 0) 就能插入渲染机会：
- 同步设置 status = 'pending'
- 微任务更新不影响渲染时机
- 用 setTimeout(() => { status = 'success'; }, 0) 把成功态推入下一宏任务
- 这样浏览器有机会在两个宏任务之间完成一次 UI 渲染，用户能看到 pending → success 的过渡
避免常见陷阱：不是所有“快”都适合微任务
微任务虽快，但滥用会导致渲染饥饿或状态错乱：
立即学习“Java免费学习笔记（深入）”；
- 在 MutationObserver 回调（微任务）里反复修改 DOM 并触发新 observer，可能造成无限循环
- 大量 Promise.then 嵌套会堆积微任务，阻塞后续宏任务（如用户输入、动画帧）
- React 中 useEffect 的清理函数和下一次 effect 启动，实际夹在微任务与宏任务之间，需注意依赖项变更节奏
- 想强制刷新视图？requestAnimationFrame 是比 setTimeout 更精准的宏任务选择，它对齐屏幕刷新率
