重绘（Repaint）的单次开销虽然不算大，但一旦高频触发——例如动画运行、页面滚动或状态频繁更新——累积起来就会导致明显的卡顿。因此，优化的核心思路并非彻底避免重绘，而是控制其频率，避免重绘成为前端性能的瓶颈。
哪些操作看似无害，实则早已暗藏性能隐患
很多人以为只修改 color 或 background-color 就万事大吉，但实际情况远比想象中复杂。浏览器判断重绘区域的逻辑相当敏感，以下操作尤其值得关注：
visibility: hidden不会触发重排（Reflow），但元素仍然占据布局位置，重绘范围会覆盖其原始布局区域。如果改用display: none，虽然会触发重排，但后续显示时的重绘区域反而更小。box-shadow和text-shadow每次发生变化时，都会强制整块渲染层（Layer）重新绘制。当阴影模糊半径较大时，像素填充量会急剧增加，性能开销不容忽视。opacity值在 0 到 1 之间连续变化时，虽然不会触发重排，但如果合成层切换失败（在旧版 Safari 或未启用硬件加速的 Chrome 中较为常见），就会降级为逐帧重绘。- 使用
filter: blur()或filter: brightness()等滤镜时，浏览器需要对整个元素进行像素级的实时处理，其重绘成本远超单纯的颜色变更。
利用 CSS 渲染层级合理隔离变化区域
浏览器以渲染层（Layer）为单位进行重绘。同一层内任意元素发生重绘，整层都需要重新渲染。因此，优化目标是明确的：将频繁变化的元素单独提取到独立的渲染层中。
- 为动画或交互元素添加
will-change: transform，可以提前告知浏览器为该元素准备独立层。但需注意不要滥用，长期开启会额外消耗内存资源。 - 使用
transform: translateZ(0)或transform: translate3d(0, 0, 0)强制创建新层，这种方法比will-change更稳定，兼容性也更出色。 - 避免让重绘元素的父容器带有
overflow: hidden或border-radius，因为这些属性会裁剪合成层，导致浏览器无法复用已有的层缓存，每次重绘都需要全量重新绘制。 - 定期检查 DevTools 的 Layers 面板，确认目标元素是否处于独立层中。如果它与文字或图片处于同一层，任何重绘都会波及这些元素。
JavaScript 控制重绘节奏的实战技巧
JavaScript 本身不会直接触发重绘，但它读写样式的方式、批量更新的时机以及事件监听的写法，都会深刻影响重绘的频率与粒度。
- 避免在
scroll或input事件中直接修改样式。即便只修改color，每次事件触发都会产生一次重绘。在 60fps 下相当于每秒 60 次重绘，性能压力极大。改用requestAnimationFrame进行节流才是正确做法。 - 不要在循环中书写
getComputedStyle(el).color这类代码。读取计算样式虽然不触发重排，但会强制同步刷新样式队列，间接拖慢整体重绘调度。 - 使用 class 切换代替内联样式修改。
el.classList.toggle('active')比el.style.color = 'red'更容易被浏览器批处理，从而有效减少重绘次数。 - 当需要批量更新多个同类元素的视觉状态时，可以先为
document.body添加一个batch-update类，然后通过 CSS 通配规则一次性生效。这种方式比逐个操作 DOM 元素高效得多。
归根结底，真正考验技术功力的地方，不在于知道该用 transform 还是 opacity，而在于准确判断某个视觉变化是否真的需要触发重绘。举个例子：按钮 hover 时添加边框，border 的变化会触发重排，但使用 outline 则仅触发重绘。正是这些细节上的选择，最终决定了页面的滚动是否流畅、动画是否掉帧。
