微任务能确保DOM更新在当前帧渲染前完成，避免过渡动画掉帧；相比setTimeout，它不延迟到下一宏任务，适合过渡前的样式准备，但不可用于读取布局属性。
微任务在动画过渡中不直接驱动帧，但能精准控制 DOM 更新时机
动画过渡（如 CSS transition 或 requestAnimationFrame 驱动的动画）是否掉帧，关键不在“有没有微任务”，而在于 DOM 变更和样式计算是否被意外推迟到下一帧。微任务本身不触发渲染，但它能确保 DOM 操作在当前帧的渲染前完成，避免因异步延迟导致样式更新滞后。
为什么用微任务比 setTimeout 更适合过渡前的 DOM 准备
在开始一个 transition 动画前，常需先修改 class、style 或属性（比如从 opacity: 0 切到 opacity: 1），但若这些修改发生在宏任务中（如 setTimeout 回调），就可能错过当前帧的渲染时机，造成首帧延迟或跳变。微任务则不同：
- 它在当前宏任务结束后、渲染前立即执行，保证 DOM 修改与当前帧绑定
- 浏览器会在同一帧内完成样式计算、布局、绘制，只要不触发强制同步布局（如读 offsetWidth）
- 相比 rAF，微任务更轻量，适合做“准备动作”而非“动画主体”
典型场景：过渡类切换时避免样式重排错位
例如点击按钮显示弹窗，希望它带 opacity + transform 过渡。错误写法是：
button.addEventListener('click', () => {modal.classList.add('show'); // 同步添加类
setTimeout(() => {
modal.style.opacity = '1'; // 延迟到下一轮宏任务 → 可能丢首帧
}, 0);
});
正确做法是把关键样式设置放进微任务：
立即学习“Java免费学习笔记（深入）”；
button.addEventListener('click', () => {modal.classList.add('show');
queueMicrotask(() => {
modal.style.opacity = '1'; // 确保在当前帧渲染前生效
modal.style.transform = 'translateY(0)';
});
});
这样既避免了同步 layout 触发，又防止了 setTimeout 的帧偏移。
搭配 requestAnimationFrame 使用效果更稳
真正需要逐帧控制的动画逻辑（如滚动跟随、物理模拟）仍应放在 rAF 回调里；微任务只负责“启动前的最后一刻设置”。常见组合模式：
- 用户交互触发后，用 queueMicrotask 批量更新多个 DOM 属性
- 紧接着在下一个 rAF 中读取 getComputedStyle 或执行动画主逻辑
- 避免在微任务里读取 offsetTop/scrollHeight 等布局属性——这会强制同步计算，反而拖慢帧率
