Chrome Performance面板可诊断动画卡顿：若Paint/Layout占比高、Composite Layers缺失，说明CSS动画未走合成器线程；应优先使用transform/opacity，避免top/width等触发重排重绘。
Chrome DevTools 里怎么看动画是否在主线程跑
动画卡顿、手机发烫，大概率是 CSS 动画或过渡被强制放在主线程执行，而不是交给合成器（compositor）处理。Chrome 的 Performance 面板能直接暴露这个问题。
打开 DevTools → Performance → 点录制（开始前勾选 Enable advanced paint instrumentation）→ 播放动画 → 停止 → 查看火焰图底部的 Layers 和 Paint 区域：
- 如果
Paint或Layout占比高，说明每次帧都在重排/重绘，动画没走合成路径 - 如果
Composite Layers几乎不出现，或者只有零星几帧有，基本确认没启用硬件加速 - 点开某帧，在右侧
Summary里看Recalc Style和Layout是否频繁触发
哪些 CSS 属性会强制触发布局/绘制，让动画变“重”
不是所有属性都能被合成器单独拎出来做动画。改了这些，浏览器必须重新计算布局或像素，CPU 就得干活：
-
width、height、top、left、margin、padding→ 触发 Layout -
background-color、border-radius、box-shadow、opacity（某些旧安卓 WebView 下）→ 触发 Paint -
transform和opacity是仅有的两个「安全」属性：只要不伴随其他副作用，它们能走合成器线程
例如：transition: top 0.3s 看似简单，但每帧都要重排；换成 transition: transform 0.3s（用 translateY() 替代 top），CPU 使用率通常直降 60% 以上。
立即学习“前端免费学习笔记（深入）”；
为什么加了 will-change: transform 还没用
will-change 不是银弹，它只是给浏览器一个提示，但能否真正创建独立合成层，取决于实际渲染上下文和浏览器策略。
- 加了
will-change: transform却没生效？先检查元素是否被父级overflow: hidden或clip-path截断 —— 这些会阻止层提升 - 动态添加
will-change（比如 hover 时加）容易引发层频繁创建/销毁，反而更耗资源；建议在动画开始前就设好，结束再移除 - 安卓低端机上，
will-change可能被忽略，或导致内存暴涨；真机测试比模拟器更可靠 - 用
transform: translateZ(0)或transform: translate3d(0, 0, 0)是更兼容的兜底方案，但注意：过度使用会吃 GPU 内存
移动端动画卡顿的隐藏元凶：非合成滚动 + position: fixed
很多“发烫”问题其实和动画本身无关，而是页面滚动时，固定定位元素（比如吸顶导航栏）不断重绘，尤其在 body 有 overscroll-behavior: contain 或用了 touch-action: pan-y 的场景下更明显。
- 用
position: sticky替代position: fixed（支持性已很好），可大幅减少合成层冲突 - 确保滚动容器是
element而非document—— 把overflow-y: scroll移到内部容器，避免整个页面滚动触发全局重绘 - 检查是否有
filter（如blur()）、backdrop-filter或透明度渐变叠加在滚动区域上，这些在 iOS Safari 和部分安卓 WebView 中无法合成
真实项目里，80% 的“动画发热”其实是滚动+固定定位+滤镜三者叠在一起，把 CPU 当成散热片用了。
