在 javascript 的事件循环中，微任务（如 promise 回调）默认是在当前宏任务结束后、下一轮渲染前执行的。要让微任务在样式计算后执行，需要利用浏览器渲染管线中“样式计算”发生在“布局/绘制”之前，而微任务在“绘制”之前执行的特性。具体做法是：先触发强制同步布局（例如读取 offsetheight），这会迫使浏览器立即完成当前的样式计算和布局；随后将逻辑放入 requestanimationframe 的回调中，或者在下一个宏任务中通过 promise.resolve().then() 执行。由于 requestanimationframe 的回调是在样式计算和布局之后、绘制之前触发的，如果在该回调中再调度一个微任务，该微任务就能确保在样式已更新但尚未绘制到屏幕时运行。
如何强制浏览器在微任务执行前完成样式计算
要确保微任务在样式计算后执行，核心在于打破浏览器的批量渲染优化，强制浏览器立即处理待处理的样式变更。这通常通过访问触发重排（Reflow）的几何属性来实现。当代码读取元素的 offsetTop、clientHeight 或调用 getBoundingClientRect() 时，浏览器会暂停脚本执行，立即运行样式计算和布局算法，以确保返回数据的准确性。完成这些步骤后，控制权交还给 JavaScript 引擎，此时可以安全地调度微任务。因为微任务的执行时机是在所有同步代码结束且下一次渲染帧开始之前，所以如果在强制布局之后调度微任务，该微任务将在新的样式状态生效但界面尚未重绘的窗口期执行。
function updateAndNotify() {
const el = document.getElementById('box');
// 修改样式
el.style.width = '200px';
// 强制同步布局：触发样式计算和重排
const height = el.offsetHeight;
// 此时样式计算已完成，调度微任务
Promise.resolve().then(() => {
console.log('样式已计算，准备绘制');
// 在这里执行依赖最新样式的逻辑
});
}
上述代码首先修改了 DOM 样式，然后通过读取 offsetHeight 强制浏览器完成内部的样式计算和布局流程。紧接着，Promise.resolve().then() 将回调加入微任务队列。当同步代码执行完毕，事件循环检查微任务队列并执行该回调。此时，DOM 的视觉表现尚未更新（因为绘制阶段还未开始），但内部样式树已经更新。这种方法适用于需要在样式变更后、用户看到变化前进行某些计算或状态同步的场景。
如何在 requestAnimationFrame 中利用微任务实现更精细的控制
除了强制同步布局，还可以结合 requestAnimationFrame (rAF) 来更优雅地控制执行时机。rAF 的回调函数会在浏览器完成样式计算和布局之后、绘制像素之前被调用。虽然 rAF 本身是一个宏任务（或称为特定类型的回调），但我们可以利用它作为锚点，在其内部调度微任务。这样做的优势在于，它不需要同步阻塞主线程去读取几何属性，而是顺应浏览器的渲染周期。在 rAF 回调中，样式已经确定，此时调度的微任务将在绘制发生前执行，从而满足“样式计算后执行”的要求。
function scheduleAfterStyleCalc() {
requestAnimationFrame(() => {
// 此时样式计算和布局已完成
Promise.resolve().then(() => {
console.log('在 rAF 回调内的微任务执行');
// 执行逻辑
});
});
}
在这个模式中，requestAnimationFrame 确保了回调执行时，浏览器已经完成了上一帧的样式计算和布局。进入回调后，我们立即使用 Promise.resolve().then() 创建一个微任务。这个微任务会在 rAF 回调结束后的极短时间内执行，依然处于同一帧的绘制阶段之前。这种方式比直接读取 offsetHeight 更平滑，因为它避免了在主线程中引发不必要的同步重排开销，特别适合动画或高频更新的场景。需要注意的是，如果 rAF 回调中还有大量同步代码，微任务可能会在这些同步代码之后才执行，因此应保持 rAF 回调内的逻辑轻量。
微任务执行时页面是否已经可见
在微任务执行期间，页面对于用户来说仍然是不可见的。这是因为微任务的执行发生在浏览器的“绘制”阶段之前。浏览器的渲染管线大致分为：样式计算 -> 布局 -> 绘制 -> 合成。微任务总是在样式计算和布局完成后、绘制开始前执行。因此，即使微任务中修改了 DOM 或 CSSOM，这些更改也不会立即反映在屏幕上。屏幕的更新要等到绘制阶段完成，并且浏览器将脏区域标记为需要重绘后，在下一次帧刷新时才会显示。这意味着，开发者可以在微任务中进行复杂的计算或状态调整，而不会导致中间状态的闪烁。只有当微任务全部执行完毕，浏览器继续执行绘制操作时，最终的视觉效果才会呈现给用户。这种机制保证了 UI 更新的原子性，避免了用户看到部分更新的界面。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
