HTML无帧率配置项，60fps是浏览器渲染流水线在理想条件下每秒约60次完整执行（样式→布局→绘制→合成）的结果；卡顿源于单帧超16.67ms，如强制同步布局；优化核心是绕开主线程瓶颈，优先用CSS transform/opacity触发GPU合成，避免重排重绘。
HTML帧率不是配置项，而是渲染结果
HTML本身没有“帧率设置”这个东西。所谓60fps，是浏览器在理想条件下每秒完成约60次完整渲染流水线（样式计算→布局→绘制→合成）的结果。它不靠frameRate或fpsLimit这类属性控制，而是由你触发的更新是否踩准了渲染节奏决定。
常见误解是“调高帧率就能更流畅”，其实反过来看更准确：卡顿不是帧率低，而是某几帧花了远超16.67ms的时间——比如一次getBoundingClientRect()触发强制同步布局，直接卡住整条渲染流水线。
- 用
requestAnimationFrame只是对齐刷新节奏，不保证每帧都来得及做完 - Chrome DevTools Performance 面板里看的是每帧耗时曲线，不是平均FPS数字；波动大的帧（比如25ms、8ms交替）比稳定45fps更让人觉得卡
- 移动端尤其明显：iOS Safari 在键盘弹出、
input聚焦时会重置合成上下文，正在跑的CSS动画可能直接中断，这不是帧率问题，是渲染层被回收了
动画优化的核心是绕开主线程瓶颈
真正起作用的不是“怎么动”，而是“谁来动”。CSS动画和JS动画走的是两条完全不同的路径：
- CSS中只用
transform和opacity，浏览器大概率会把它提升到独立合成层，由GPU直接处理，主线程几乎不参与 - JS里用
requestAnimationFrame改left或width，每次都要触发样式计算+布局+重绘，哪怕只改一个像素，也得重跑整条流水线 -
will-change: transform不是万能加速器——它只是个提示，而且加早了（比如悬停就加）或加多了（全页面十几个元素）反而让浏览器预分配资源失败，导致更卡
简单验证：打开DevTools → Rendering → 勾选“Paint flashing”，如果爱心动画区域频繁闪绿，说明在重绘；闪灰，说明在重排——后者基本等于动画已掉帧。
立即学习“前端免费学习笔记（深入）”；
requestAnimationFrame回调里只能做两件事
很多人把requestAnimationFrame当成了“更高级的setTimeout”，结果在里面塞查询DOM、拼字符串、甚至调JSON.parse()，这完全违背设计初衷。
- 回调内只允许做：状态更新（如
position += velocity * deltaT） + 样式设置（如el.style.transform = `translateX(${x}px)`） - 所有DOM读取（
offsetTop、getBoundingClientRect()、scrollHeight）必须集中到一帧开头，且尽量缓存；所有写入必须集中到一帧结尾 - 如果动画逻辑依赖复杂计算（比如贝塞尔插值、碰撞检测），提前算好存进数组，回调里只查表；实在绕不开，丢给
Web Worker，主线程只收结果
顺带一提：setInterval(gameLoop, 16)这种写法在后台标签页或CPU繁忙时会严重漂移，甚至累积几十帧未执行，切回来瞬间全补上——用户看到的就是一顿乱跳。
Canvas动画卡顿往往和抗锯齿、像素操作强相关
Canvas看似自由，但默认行为对性能极不友好：
-
ctx.imageSmoothingEnabled = true（默认）会让任何缩放/旋转操作触发高质量重采样，低端机上一帧卡死 - 每帧调用
getImageData()或putImageData()，等于把整块像素内存从GPU拷回CPU再拷回去，是典型的主线程杀手 - 加了
filter: blur(2px)或drop-shadow()的Canvas容器，浏览器无法将其升为合成层，整个画布退化成CPU渲染，但控制台不会报错
实操建议：静态背景用离屏canvas预渲染好，主画布只负责drawImage；粒子多时拆成多个canvas层，各自用不同requestAnimationFrame节奏更新；缩放务必用整数倍，避免插值计算。
最易被忽略的一点：动画元素若含filter，哪怕只是opacity过渡，只要父容器有filter，子元素也会失去合成资格——这种卡顿无声无息，只能靠DevTools的Layers面板确认。
