重绘开销小但高频触发致卡顿，关键在于避免成为性能瓶颈；需警惕看似安全的操作（如color、opacity、filter等）仍会扩大重绘范围，应通过分层（will-change/translateZ）、JS节流（rAF）、class切换等方式精准控制重绘粒度。
重绘本身开销不大，但高频触发会累积成卡顿——尤其在动画、滚动或频繁状态更新场景下。关键不是“避免重绘”，而是“不让它成为性能瓶颈”。
哪些操作看似安全，实则偷偷触发重绘
很多人以为只改 color 或 background-color 就万事大吉，但实际中这些操作仍可能被浏览器判定为需重绘的区域扩大：
-
visibility: hidden不触发重排，但元素仍占位，重绘范围包含其原始布局区域；换成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 面板，确认目标元素是否真在独立层；若和文字、图片挤在同一层，重绘就会波及它们
JS 控制重绘节奏的实操要点
JavaScript 不直接触发重绘，但它读写样式、批量更新时机、甚至事件监听方式，都会影响重绘频率和粒度。
立即学习“前端免费学习笔记（深入）”；
- 避免在
scroll或input事件里直接改样式：哪怕只改color，每帧都触发一次重绘，60fps 下就是每秒 60 次；改用requestAnimationFrame节流 - 不要在循环里读取
getComputedStyle(el).color—— 它虽不触发重排，但会强制同步刷新样式队列，间接拖慢重绘调度 - 用 class 切换代替内联样式修改：
el.classList.toggle('active')比el.style.color = 'red'更易被浏览器批处理，减少重绘次数 - 对多个同类型元素做统一视觉更新时，先用
document.body.classList.add('batch-update')触发 CSS 通配规则，比逐个操作 DOM 更高效
真正难的不是知道该用 transform 或 opacity，而是判断某个视觉变化是否真的需要重绘——比如一个按钮 hover 时加边框，border 改变会触发重排，但用 outline 就只重绘；这种细节，往往决定滚动是否顺滑、动画是否掉帧。
