JavaScript 通过 element.style 设置的 CSS 属性会立即同步更新 DOM 的计算样式，但实际视觉渲染需等待浏览器下一帧绘制；可通过嵌套 requestAnimationFrame 精确捕获样式应用后的渲染完成时机。
在日常 Web 开发中，我们经常遇到这样的需求：使用 element.style.color = "red" 动态修改样式后，紧接着需要读取元素尺寸、触发动画或验证样式是否真正呈现到屏幕上。此时，一个关键问题随之浮现——样式赋值本身是同步且即时生效的，赋值后立即调用 getComputedStyle(elem).color 确实能获取到最新值。但问题的核心在于：这个新样式是否已经真实地出现在了用户的可视区域中？
要理解这一点，需要回顾浏览器的完整渲染流水线。一个典型的渲染周期涵盖样式计算、布局（Layout）、绘制（Paint）和合成（Composite）等多个阶段。这些步骤并不会在 JavaScript 执行期间即时触发，而是统一安排在下一帧绘制之前集中处理。换句话说，当你修改 style 属性时，浏览器只是将变更记录到“待处理队列”中，真正的视觉呈现要等到下一个渲染帧才会执行。
如果想精准捕捉到“样式真正绘制完成”的时机，最可靠的方式就是使用 requestAnimationFrame（简称 rAF）。它会在浏览器下一次重绘之前执行回调，确保你的样式变更已经进入了渲染管线。但如果你的需求是获取“样式在视觉上完全可见”之后的时刻——例如读取 offsetHeight 或启动一个依赖视觉状态的动画——那就需要再加一道保险。
业内推荐的做法是采用双层 rAF 机制：
function executeAfterCSSAppliedToDOM(callback) {
requestAnimationFrame(() => {
requestAnimationFrame(() => {
callback();
});
});
}
// 使用示例
const elem = document.querySelector("#abc");
elem.style.color = "red";
elem.style.transform = "scale(1.2)";
executeAfterCSSAppliedToDOM(() => {
// 此时 color 和 transform 已参与布局与绘制计算
console.log("样式已渲染：", getComputedStyle(elem).color); // "rgb(255, 0, 0)"
console.log("元素高度已更新：", elem.offsetHeight);
});
✅ 为什么双层 rAF 能精准捕获渲染完成时机？
- 第一层 rAF 确保回调在当前帧的绘制前执行，此时样式计算已完成，但布局和绘制可能尚未就绪；
- 第二层 rAF 将回调推迟到下一帧的绘制之前，此时浏览器已经完成了样式解析、布局计算和绘制准备的全部流程。此时再去读取
getComputedStyle或几何属性（如offsetHeight），它们反映的正是最新的渲染状态。
⚠️ 需要特别留意的几个常见误区：
- 不要用
setTimeout(fn, 0)来替代 rAF。它不与渲染帧对齐，可能在绘制前或绘制后的任意时刻触发，结果极不稳定，完全不可信赖； - 不要指望
MutationObserver来监听 style 属性的变化。它只能感知 DOM 属性的变更，却无法得知浏览器是否已完成样式计算和渲染； - 如果你的场景涉及 CSS 过渡（transition）或动画（animation），仅靠 rAF 是不够的。这时应当监听
transitionend或animationend事件，它们才是真正的“视觉完成信号”。
总而言之，style 赋值是同步操作，在 DOM 模型层面会立即生效；但视觉呈现必须遵循浏览器的渲染时序。掌握双层 rAF 这一技巧，才能真正把握住样式从生效到渲染的完整生命周期。
