重绘本身不触发重排，但频繁重绘或未隔离绘制区域会导致卡顿；需警惕看似仅改外观却隐含重排的操作，以及合理使用contain: paint、图层提升和requestAnimationFrame优化。
重绘（repaint）本身不改布局，但频繁触发仍会卡顿；真正要盯住的，是那些“看似只改颜色、实则偷偷拉上重排”的操作，以及没被隔离的绘制区域。
哪些 CSS 属性改了会触发重绘
color、background-color、border-color、visibility、outline、box-shadow、text-decoration 这类纯外观属性，改了只走 paint 阶段，不触 layout。但注意两个坑：
-
visibility: hidden虽然不重排，但元素仍占文档流位置，且仍响应事件；真要彻底“隐身”，得配pointer-events: none或display: none（后者会触发重排） -
opacity改变确实只重绘，但前提是元素已独立成层；否则 opacity 动画可能降级为软件渲染，帧率不稳 - 动画中用
filter: blur()或filter: brightness()看似只动外观，实际会强制创建新图层并触发额外合成开销，移动端尤其敏感
为什么加了 contain: paint 还在重绘整个页面
contain: paint 的作用是告诉浏览器：“这个容器内的像素变化，不会影响外部绘制”，但它不阻止内部重绘——只是把重绘范围锁死在该容器内。常见失效原因：
- 容器本身没设明确宽高（比如
height: auto且子元素浮动），导致浏览器无法确定绘制边界 - 子元素用了
position: fixed或position: absolute且偏移超出容器，绘制区域溢出，contain 失效 - 父级或祖先节点设置了
transform或opacity，意外创建了包含关系，把本该隔离的绘制又卷进去了
验证是否生效：Chrome DevTools → Rendering → 勾选 “Paint flashing”，动一动目标区域，看高亮是否严格局限在容器内。
立即学习“前端免费学习笔记（深入）”；
用 requestAnimationFrame 控制重绘节奏有用吗
有用，但仅限于你主动触发的重绘场景，比如滚动中动态更新文字阴影、hover 时渐变背景色。它不能阻止浏览器自动触发的重绘，也不能跳过 paint 阶段本身。
- 关键不是“用不用
requestAnimationFrame”，而是“有没有把读写操作拆开”：先批量读取（如所有offsetTop），再批量写入（如统一设style.transform），最后用requestAnimationFrame批量提交 - 如果在
requestAnimationFrame回调里又读了getComputedStyle()，等于白套——同步布局计算照常触发 - 动画帧率卡在 60fps 不代表流畅，要关注每帧耗时是否稳定；
performance.now()打点比单纯看 FPS 更准
opacity 动画卡顿，是不是该换回 background-color
别换。opacity 卡顿大概率不是属性问题，而是图层管理出了状况：
- 检查是否漏了提升图层：只写
opacity: 0.8不够，得配合transform: translateZ(0)或will-change: opacity（注意 Safari 对后者支持弱） - 大量同级 opacity 元素同时动画，GPU 纹理上传争抢严重；可错开启动时间，或用
contain: strict把它们分到不同合成层 -
opacity和transform混用时，若 transform 值含小数（如translateX(10.3px)），可能触发亚像素渲染，反复重绘；强制整数对齐更稳
真正容易被忽略的是：重绘成本不只在“画多少”，更在“画多频繁”和“画哪一块”。一个没 contain 的轮播图，哪怕只动 opacity，每次切换都在重绘整个视口；而加了 contain: paint 的同一组件，重绘区域可能只有 200×150px。差的不是代码行数，是浏览器是否敢信任你。
