帧率低是动画卡顿的结果而非原因，真正拖慢动画的是渲染路径错误、主线程阻塞或合成层缺失；fps仅为诊断指标，需通过performance面板定位layout/paint耗时、避免强制同步布局、合理使用css合成与canvas优化来解决。
帧率本身不会拖慢动画，但帧率低是动画已卡顿的结果，不是原因——真正拖慢动画的是渲染路径错误、主线程阻塞或合成层缺失。
为什么盯着FPS数字优化反而容易走偏
很多人一看到控制台打印出 42 FPS 就立刻去“提升帧率”，结果改了一堆 will-change 和 transform，动画还是卡。因为 FPS 是诊断指标，不是可直接调节的开关。
- 浏览器无法“提高帧率”，它只能尽力在 16.67ms 内完成一帧：样式计算 → 布局 → 绘制 → 合成
- 你看到的低 FPS，其实是某一步耗时超标（比如 layout 占了 25ms），导致掉帧
- Chrome DevTools Performance 面板里，重点看每帧的「长条颜色」：紫色（layout）和绿色（paint）突然变宽，才是真问题
requestAnimationFrame 里最常踩的三类坑
用 requestAnimationFrame 不等于动画就流畅。下面这些操作会悄悄把一帧拖到 30ms 以上：
- 在回调里调用
offsetTop、getBoundingClientRect()或clientWidth—— 触发强制同步布局（Forced Layout） - 每帧都执行 DOM 查询，比如反复写
document.querySelector('.heart') - 在动画循环里做耗时计算（如贝塞尔插值、大量数组遍历），没拆到
queueMicrotask或 Web Worker
正确做法是：只更新状态 + 只设置样式。其他事全挪出去。
CSS 动画卡在 30fps 的隐蔽原因
写了 @keyframes，加了 transform，为什么还是只有 30fps？常见却被忽略的几点：
-
filter: blur(2px)或drop-shadow()会让元素退回到 CPU 渲染，合成层失效 - 父容器用了
overflow: hidden且子元素正在translateX，可能触发额外裁剪计算 -
will-change: transform没在动画开始前加，或加了不移除，导致浏览器长期维持合成层开销 - 动画元素有透明度渐变但同时设置了
background: rgba()，alpha 混合开销翻倍
Canvas 动画掉帧却不报错的信号
Canvas 看似“底层”，其实更容易因细节失控掉帧。以下现象出现时，基本可以判定是 Canvas 渲染瓶颈：
- 动画在高刷屏（120Hz）上反而更卡——说明没做时间戳位移，还在用“每帧 +2px”硬编码
- 开启
ctx.imageSmoothingEnabled = true（默认值）后旋转/缩放爱心，GPU 负载飙升 - 每帧都调用
ctx.getImageData()处理像素，哪怕只读不写，也会强制同步回 CPU - 所有图层画在一个 canvas 上，粒子+文字+背景共用一个上下文，重绘面积远超必要
真正难调试的，是那些不抛错、不警告、只让帧持续时间忽高忽低的合成层降级——它不会打断 JS，但会让用户明显觉得“不对劲”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
