getcomputedstyle 会强制同步布局（即触发重排），导致后续 transform 修改无法复用已有合成层，被迫降级为重绘甚至重排，引发动画卡顿；应缓存读取结果、避免在动画或事件中混用读写操作。
为什么 getComputedStyle 会悄悄触发重排，还让合成层失效
当你在 JS 中调用 getComputedStyle(element) 后紧接着改 element.style.transform，看似只动了合成属性，但浏览器其实已经“被迫回流”了一次——因为 getComputedStyle 是强制同步布局的 API。一旦同步布局发生，后续哪怕只改 transform，浏览器也可能放弃复用已有合成层，转而降级到重绘甚至重排路径。
常见错误现象：transform 动画突然卡顿、FPS 掉到 30 以下、Performance 面板里出现大量绿色（Paint）和黄色（Layout）长条。
- 不要在动画循环中读取任何布局相关属性：包括
offsetHeight、clientWidth、scrollTop、getComputedStyle - 若必须读取，缓存一次结果，后续复用；或把读取操作移到
requestAnimationFrame开始前统一做 - 检查是否无意中在事件回调（如
scroll、resize）里混用了读+写，这是最隐蔽的重排来源
如何确认某个元素是否真的走合成，而不是假性“硬件加速”
很多人加了 will-change: transform 或 transform: translateZ(0) 就以为进了 GPU 合成层，但 Chrome DevTools 的 Layers 面板会告诉你真相：它只显示当前被提升为独立图层的元素，且仅当该图层正在被合成线程使用时才高亮。
实操建议：
- 打开 DevTools →
More Tools→Layers面板，滚动/交互页面，观察哪些区域有蓝色边框（表示独立图层） - 点击图层可查看详细信息，重点关注
Composited状态是否为true，以及Reasons for compositing是否包含will-change或transform - 如果看到
Reasons for compositing: “layer-for-transform”却仍有重绘，说明该图层内容频繁变更（比如内联样式被 JS 反复修改），导致光栅化（Raster）任务频繁，GPU 合成线程反而被拖慢
transform 和 left/top 在 Performance 面板里的行为差异
在 Performance 面板录制一段动画后展开 Main 线程时间线，你能清晰看到两者的执行路径完全不同：
- 用
left：每帧都触发 Layout（黄色块）→ Paint（绿色块）→ Composite（浅蓝块），主线程满载 - 用
transform：只有 Composite（浅蓝块），Layout 和 Paint 基本消失，主线程空闲 - 但如果 JS 在每帧里都调用
element.style.transform = 'translateX(...)' + Math.random()，且没做字符串拼接优化，V8 可能因频繁创建新字符串触发 minor GC，间接影响帧率——这不是渲染问题，但会被误判为“合成卡顿”
关键点：合成层本身不保帧率，它只保证不触发 Layout/Paint；真正的流畅依赖于 JS 执行轻量、无同步阻塞、且图层内容稳定。
怎么揪出“本该合成却重绘”的真实原因
最常被忽略的是 CSS 层面的隐式降级：即使你写了 transform，只要元素上有 filter、mask、clip-path 或透明度渐变（opacity 动画混用 background-color），浏览器可能拒绝复用已有合成层，转而每次重绘整个图层。
- 在 Elements 面板选中目标元素，右键 →
Force element state→ 勾选:hover或其他伪类，看是否意外触发重绘 - 检查 computed 样式中是否有未预期的
contain: paint或overflow: hidden，它们会限制图层边界，导致合成策略变化 - 在 Rendering 面板勾选
Layer borders和FPS meter，边操作边观察：如果图层边框闪烁或数量突增，说明 JS 正在反复创建/销毁图层
真正难调试的不是“没合成”，而是“合成了但没用好”——图层存在，却被迫反复光栅化，或因 JS 干预打断了合成线程的连续性。
