transform和opacity仅触发合成；width、height、top、left、background-color等触发重排+重绘；box-shadow、border-radius、color、font-size可能间接引发重绘或重排。
哪些CSS属性触发重绘，哪些直接走合成？
浏览器对不同CSS属性的响应机制差异极大。改 transform 或 opacity 通常只触发合成（compositing），不走布局（layout）和重绘（paint）；但动 width、height、top、left、background-color 就大概率触发重排+重绘，开销高得多。
-
transform和opacity是“安全区”，尤其适合动画场景 -
box-shadow、border-radius看似轻量，但频繁变更仍可能触发重绘（尤其在低端设备上） -
color、font-size改变文本样式时，若影响行高或换行位置，会间接引发布局重排
用 Chrome DevTools 的 Rendering > Paint flashing 可直观看到哪些区域被重绘——别只信文档，实测为准。
用will-change提前提示浏览器，但别滥用
will-change 不是性能银弹，它只是告诉浏览器：“这个元素接下来可能会变，请提前准备图层”。但它本身就有开销：强制提升为独立图层，消耗内存，还可能干扰浏览器的自动优化策略。
- 只对明确要动画、且持续时间 > 200ms 的元素设
will-change: transform - 动画结束立刻移除，比如用 JS 监听
transitionend后设will-change: auto - 绝对不要写
will-change: all或批量给列表项加该声明——内存暴涨、滚动卡顿立马出现
示例：
立即学习“前端免费学习笔记（深入）”；
button:hover { will-change: transform; }
button:active { transform: scale(0.95); }
button:focus:not(:active) { will-change: auto; }避免在JS中频繁读写offsetTop/offsetHeight等布局属性
这类属性会强制浏览器同步计算当前布局（即触发 layout thrashing），打断渲染流水线。哪怕只是循环里读一次 offsetTop，再改一次 top，都可能让浏览器反复回流。
- 把所有读操作集中到一起，所有写操作集中到一起（“读-改-写”三步拆开）
- 优先用
getBoundingClientRect()替代多个 offsetXXX 属性组合 - 更彻底的做法：用
requestAnimationFrame批量处理，确保 DOM 更新落在下一帧
常见错误现象：
- 下拉菜单滚动时卡顿，实际是每次 scroll 事件里都在读
clientHeight+ 改max-height - 列表项 hover 高亮变慢，背后是 JS 每次都查
offsetLeft再算定位
用CSS变量+transform替代动态内联style
很多人习惯用 JS 直接改 element.style.left = x + 'px'，这等于每帧都触发布局。换成 CSS 变量配合 transform，把计算交给 CSS 引擎，更稳也更快。
- 在根元素或父容器定义
--x: 0，然后用transform: translateX(calc(var(--x) * 1px)) - JS 只负责更新
document.documentElement.style.setProperty('--x', newX) - 注意：CSS 变量不能直接用于
transition，需配合@property（仅现代浏览器支持）或 fallback 到 class 切换
兼容性提醒：
-
@property在 Safari 16.4+、Chrome 110+ 可用，旧环境仍得靠 class 控制 transform 值 - 不要试图用
transition过渡 CSS 变量本身——它不会动画，只会跳变
重绘不是黑箱，关键在分清“浏览器真要重画”和“你让它以为要重画”。很多优化失败，不是代码写错，而是没看清 DevTools 里那一闪而过的黄色 paint 区块到底从哪来。
