如何通过“读写分离”策略有效规避 JS 频繁操作导致的页面帧率抖动
问题的核心，其实在于把“读布局”和“写样式”这两件事彻底拆开，别让它们在同一轮 Ja vaScript 执行里混着来。这样一来，浏览器才有机会把一堆写操作攒起来，推迟到下一帧之前统一处理，从而避免反复触发代价高昂的回流（reflow）。
为什么混着读写会抖动
想象一下这样的场景：你连续执行了几行看似无害的代码。
- 先来一句
element.offsetHeight（这是一次“读”操作，会强制浏览器立刻计算当前的布局状态）。 - 紧接着又是一句
element.style.width = '300px'（这是一次“写”操作，要求改变布局）。
这下麻烦了。浏览器没办法，只能中断正在进行的渲染流水线，当场执行一次重排。如果下一行代码又是类似的“读-写”组合，那么整个过程就得再来一遍。如此循环几十次，页面的帧率很容易就会跌破 30fps，卡顿感也就肉眼可见了。
怎么真正实现读写分离
实现读写分离，可不是简单加个 setTimeout 就万事大吉了。这里的关键在于顺序控制：
- 集中读取：把所有需要读取布局属性的操作（比如
offsetTop、getBoundingClientRect()、clientWidth等）集中放在一个代码块里，一口气读完。 - 批量写入：把所有修改样式的操作（无论是直接设置
style.xxx，还是修改className，或是setAttribute('style', ...)）全部挪到所有读取操作完成之后，并且尽量批量完成。 - 巧用替代方案：如果逻辑上确实需要在读取某个值后立即进行样式调整，可以尝试使用
getComputedStyle(element).height来替代clientHeight。前者通常不会触发强制性的同步布局计算。
配合 CSS 和 API 效果更稳
仅仅调整 Ja vaScript 的执行顺序有时还不够。要想效果更稳固，最好能从渲染机制上想办法，直接绕开布局计算：
- 动画优先 GPU：对于动画类的样式变更，优先使用
transform和opacity属性。它们由合成线程处理，完全不会触发布局或绘制。 - 提前升层：对于需要频繁更新的元素，可以提前为其加上
will-change: transform属性。这相当于给浏览器一个提示，让它提前将该元素提升到独立的合成层。 - 善用 CSS 原生能力：像实现吸顶导航这类效果，直接使用
position: sticky往往比用 Ja vaScript 动态切换fixed定位更安全、更高效，因为它不会引发整个页面高度的跳变。
验证是否生效的小技巧
理论说再多，不如实际验证一下。打开 Chrome 开发者工具，按照以下步骤操作：
- 进入 “Rendering” 面板。
- 勾选 “Layout Shift Regions” 和 “FPS Meter” 两个选项。
- 然后去滚动页面或触发相关交互。
观察结果：
- 如果页面上的红色闪烁区域（表示布局偏移）大幅减少，并且 FPS 曲线平稳地维持在 55–60 帧之间，恭喜你，说明读写分离策略生效了。
- 如果性能面板的时间轴上仍然频繁出现黄色的 “Layout” 区块，那就意味着还有隐藏的同步读写操作没被清理干净。这时候，就需要重点检查一下第三方库的代码或者某些事件回调函数里的 DOM 访问逻辑了。
