关键是要用Chrome DevTools Performance面板录帧分析，重点关注FPS曲线红条、Main线程中Layout/Paint耗时及Layers面板图层状态，结合属性触发阶段对照表（transform/opacity安全，top/width等危险）和JS同步布局读取行为排查真因。
检测和排查 CSS 动画丢帧卡顿，关键不是“看动得顺不顺”，而是用工具定位哪一环拖了后腿。浏览器渲染流水线里，只要某帧在 Layout、Paint 或 Composite 阶段超时（超过 16.7ms），就会掉帧。下面这些方法能帮你快速揪出真凶。
用 Chrome DevTools 的 Performance 面板录帧分析
这是最直接有效的手段。打开 DevTools → Performance → 点录制 → 播放动画 → 停止。重点关注三块：
- 火焰图顶部的 FPS 曲线：绿色代表稳定 60fps，黄色/红色说明掉帧；点红条会高亮对应帧
- 底部的 Main 线程时间轴：看是否有长任务（>16ms 的紫色/橙色块），尤其注意 Layout 和 Paint 占比是否异常高
- Layers 面板（需在 More Tools 中开启）：检查图层数量是否过多（>30 层易引发合成压力），以及某个元素是否意外没升层（本该独立合成却和背景混在一起）
识别哪些 CSS 属性正在拖慢动画
动画卡顿往往源于“看起来一样、实际开销天差地别”的写法。对照这个底线原则判断：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 安全属性（只走 Composite）：transform（translate/scale/rotate）、opacity —— 它们不改布局、不重绘，GPU 合成线程直接处理
- 危险属性（必触发 Layout 或 Paint）：top/left/width/height/margin/padding → 触发重排；color/background-color/box-shadow/filter → 触发重绘
- 特别注意隐式降级：哪怕 @keyframes 里 99% 都用 transform，只要混进一个 left 或 background-color，整段动画就退回 CPU 渲染
检查 JavaScript 是否在干扰渲染
JS 不一定在“写动画”，但可能悄悄制造同步布局瓶颈：
立即学习“前端免费学习笔记（深入）”；
- 在 requestAnimationFrame 回调或动画过程中读取 offsetTop、getBoundingClientRect、clientWidth 等布局信息，会强制浏览器立刻执行 Layout，打断流水线
- 频繁增删 class、修改 style 属性又立刻读取，形成“读-写-读”循环，极易引发布局抖动
- 解决方案：把布局读取操作集中提前做；用 ResizeObserver 替代轮询；动画中只做纯样式写入（如 element.style.transform = '...'）
验证合成层与硬件加速是否真正生效
写了 transform 并不等于自动升层，尤其在复杂 DOM 结构或嵌套变换下：
- 用 Layers 面板确认目标元素是否拥有独立图层（有独立纹理、带“Composited layer”标签）
- will-change: transform 是提示，不是保证 —— 静态写死会导致内存浪费，应在动画开始前 JS 动态设置，并在 transitionend 或 onfinish 后立刻设回 auto
- 慎用 translateZ(0) 强制升层：它确实能触发合成，但无差别加会给低端安卓机带来明显内存压力，仅用于确认问题时临时验证
