分享一个提升页面性能的经验：直接修改CSS类名来批量调整样式，远比逐个修改元素样式更高效。原因在于，浏览器会将样式修改暂存并批量处理，但若你在读取布局信息（如offsetHeight）之前更改了DOM，浏览器便只能立即进行强制重算。这并非玄学，而是你中断了渲染队列的积累过程。
哪些常见操作会强制触发浏览器回流与重绘？
只要浏览器需要重新计算元素的几何信息（位置、尺寸、是否可见），就会触发回流。常见动作包括：
- 当读取
offsetTop、offsetWidth、getComputedStyle()等布局相关属性时，若此前存在尚未刷新的样式修改，浏览器会立即执行一次强制回流（layout）。 - 修改
width、height、padding、margin、display、font-size等样式属性。 - 添加或删除可见的DOM节点，或调用
appendChild()、removeChild()等方法。 - 窗口大小改变（resize）以及滚动操作（尤其监听
scroll事件时未做节流处理）。 table元素任意改动——哪怕只修改一个单元格的边框，整个表格都可能触发重排。
为何集中写入样式比逐个赋值更高效？
浏览器内置了渲染队列机制，用于暂存样式写入操作，待JavaScript执行完毕后统一刷新。然而，若在写入样式过程中穿插读取布局属性的代码，渲染队列将被强制提前执行，从而引发多次不必要的回流。
错误写法示例：
el.style.width = '200px';el.style.height = '100px';console.log(el.offsetHeight); // 触发一次回流el.style.background = 'red'; // 又触发一次回流（因上一步已flush）
正确的做法是读写分离，并批量写入：
// 先读完所有需要的值const h = el.offsetHeight;const w = el.offsetWidth;// 再一次性改样式el.className = 'card-active';// 或用CSSOM批量设置Object.assign(el.style, { width: '200px', height: '100px', background: 'red'});
display:none 与 visibility:hidden 的性能差异远不止于可见性
这是最容易被忽略的性能优化关键点：
display: none：元素会彻底脱离渲染树，对其进行的任何DOM操作（增删子节点、修改class、设置style）都不会触发回流或重绘。visibility: hidden：元素仍然保留在渲染树中，只是不绘制；修改它的color或background属性仍会触发重绘。- 因此，在执行批量DOM操作前，可先通过
el.style.display = 'none'将元素隐藏，操作完成后再恢复显示，这比反复触发布局计算要快得多。
动画优化中，requestAnimationFrame 并非万能方案
很多人误以为使用 requestAnimationFrame 就能自动优化性能，实际上并非如此：
- 如果每一帧都读取
offsetLeft再修改transform，依然会在每一帧触发回流。 - 真正高效的做法是：只读取一次布局信息（例如初始位置），后续动画仅使用
transform或opacity属性，它们会走合成层，不会触发布局计算。 - 应避免在rAF回调内部调用
getBoundingClientRect()或scrollIntoView()等可能触发回流的API。
一个常被忽略的优化点：在CSS中使用 will-change: transform 提前声明动画属性，可让浏览器提前进行图层提升，避免动画过程中突然升层导致的卡顿。但需注意，此属性并非万能，滥用反而会增加内存开销。