真正走GPU合成层的只有transform和opacity，因它们不触发layout和全量paint，由合成线程在GPU处理；其他属性如background-color、margin等均导致CPU渲染降级。
只用 transform 和 opacity 才真正走 GPU 合成层
浏览器对 transform（如 translateX、scale、rotate）和 opacity 做了硬编码优化：它们不参与 layout 计算，也不触发全量 paint，而是交由合成线程在 GPU 上直接处理图层位移或混合。其他属性哪怕只是 background-color 或 margin，都会拉整个动画降级到 CPU 渲染。
常见错误现象：
-
transition: left 0.3s导致滚动中动画卡顿、掉帧 - 写了
transform: translateZ(0)却没绿框——说明根本没提层 - hover 时元素“跳一下”，是因为初始
transform值没显式声明
实操建议：
- 位移必须用
transform: translateX(10px)，别混搭left: 10px -
opacity只接受 0–1 的小数，opacity: 50%是非法写法，会静默失效 - 初始值必须显式写出，比如
transform: translateY(0)，否则第一帧可能突变
为什么加了 translate3d 还没加速？检查父容器是否压制图层
给元素加 transform: translate3d(0, 0, 0) 或 will-change: transform，只是“请求”浏览器建独立合成层，不是强制指令。如果父容器存在以下任一情况，子元素的图层提升就会被抑制：
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden（最常见，但也是隔离渲染边界的必要手段） -
filter（哪怕只是filter: blur(1px)） -
mask、clip-path - 非 identity 的
transform（如rotate(0.1deg)）
验证是否生效的唯一方式是打开 Chrome DevTools → Rendering 面板 → 勾选 “Layer Borders”：有绿色边框才表示真提层成功。没绿框时，优先排查父级样式而非子元素写法。
will-change 不是开关，是“临时预告”
will-change: transform 的作用是提前告诉浏览器：“这个元素接下来 1–2 帧内大概率要动”，让其预分配 GPU 图层资源。但它不是魔法开关，静态全局写死反而有害。
实操建议：
- JS 中在动画触发前（例如
touchstart或mouseenter）设el.style.willChange = 'transform' - 监听
transitionend后立刻清除：el.style.willChange = 'auto' - iOS Safari 对极短动画（≤16ms）可能不触发
transitionend，加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 绝对不要写
* { will-change: transform; }—— 安卓低端机容易 OOM
移动端特别注意：小数位移和合成层数量
iOS Safari 对 sub-pixel 位移极其敏感：translateX(0.001px) 可能被忽略；Android WebView 则对合成层数量更苛刻——每多一个图层，GPU 显存占用就涨一点，加载动画满屏时容易卡顿。
关键细节：
- 位移步进建议 ≥
0.01px，或直接用整数（translateX(1px)） - 动画持续时间
- Grid 布局中单个
img缩放导致后续所有兄弟重绘，本质是共享绘制层未拆分，加transform: translateZ(0)或 Tailwind 的transform-gpu可隔离图层 - 父容器加
overflow: hidden是最简单有效的渲染边界隔离方式，但要注意它本身会压制子层——需权衡
最容易被忽略的是父容器：哪怕子元素写得再规范，只要父级带 filter 或 overflow: hidden，GPU 加速就形同虚设。
