transform和opacity能触发硬件加速，因二者可独立创建合成层且不引发布局或绘制；其他属性如width、height等会强制重排重绘。
为什么transform和opacity能触发硬件加速
浏览器对某些 CSS 属性的变更可以绕过重排（reflow）和重绘（repaint），直接交由 GPU 处理。其中 transform 和 opacity 是仅有的两个能独立触发合成层（compositing layer） 且不引发布局或绘制的属性。其他如 width、height、top、left、background-color 都会强制触发重排或重绘，动画一卡就是一卡。
关键不是“用了GPU”，而是“只动合成层”。一旦元素进入自己的合成层，后续 transform 平移/缩放/旋转、opacity 透明度变化，就只是 GPU 上的图层操作，不牵扯主线程样式计算和绘制流水线。
哪些写法看似用了transform，实际没触发硬件加速
常见错误是让浏览器“不敢”提升图层，结果白写了 transform：
- 父元素设置了
overflow: hidden或clip-path，可能抑制子元素的层提升 - 元素本身有
will-change: auto（默认值）或未声明will-change，而动画又没提前“预告” - 用
transform: translateX(10px)动画，但起始状态是transform: none—— 浏览器可能延迟提升，首帧掉帧 - 同时修改
transform和color或border，后者会拉整个元素回主线程重绘
实操建议：动画前主动创建合成层，比如加 will-change: transform（仅对即将动画的元素），或用 transform: translateZ(0) / transform: scale(1.0001) 强制提升（慎用，别滥用）。
立即学习“前端免费学习笔记（深入）”；
opacity动画卡顿？检查是否被其他属性拖下水
opacity 本身极轻量，但常因配套操作失效：
- 和
visibility混用：设visibility: hidden会卸载图层，再设opacity: 0就没意义了 - 父容器有
filter（如blur()、drop-shadow()），会导致子元素无法单独合成，整个滤镜区域被当作一个大图层处理，opacity变更也要重绘该区域 - 动画中动态插入/删除 DOM 节点，触发 layout，打断合成流
- 使用
transition: all 0.3s，哪怕只改opacity，浏览器也可能为其他潜在属性预留重绘通道
正确写法是精准过渡：transition: opacity 0.3s ease，并确保父级没意外施加 filter 或 mask。
Chrome DevTools里怎么验证是否真走GPU加速
别靠感觉，看真实层树：
- 打开 Chrome DevTools → Layers 面板（需在
More Tools → Layers中启用） - 播放动画时观察：有独立图层的元素会显示为一块彩色矩形，标着 “Composited layer”
- 如果只有主文档层（Document Layer），说明没分层；如果看到“Paints on scroll”或“Scrolls with page”，说明还在主线程滚动/绘制
- 右键元素 → Inspect Element → 在 Styles 面板里看 computed 的
transform是否显示为matrix3d(...)（GPU路径），而非matrix(...)（CPU路径）
容易被忽略的是：动画结束后图层可能被回收。所以要抓“动画进行中”的瞬间，而不是停帧后看。
