高刷新率屏幕下css动画掉帧的根源是“时间精度错配”。浏览器在60hz下按16.67ms调度，而120hz/144hz需8.33ms/6.94ms，系统默认帧节奏与高刷不匹配，尤其低端gpu或webview中合成线程仍按旧节拍提交图层，导致跳帧、重复帧或延迟渲染。
高刷新率屏幕下CSS动画掉帧的根源是“时间精度错配”，不是性能不足
浏览器在60Hz屏幕下按16.67ms一帧调度动画，但120Hz或144Hz屏要求8.33ms或6.94ms一帧。当CSS动画依赖系统默认帧节奏（如transition或@keyframes未显式控制时序），浏览器可能无法稳定输出对应高刷帧——尤其在低端GPU或WebView中，合成线程仍按旧有节拍提交图层，导致跳帧、重复帧或延迟渲染。
transform/opacity在高刷屏上也会卡，关键看是否触发强制同步布局
即使只用transform和opacity，以下情况仍会破坏高刷稳定性：
- JavaScript中在
requestAnimationFrame回调里读取offsetTop、getBoundingClientRect()后立即修改style.transform，触发强制同步布局，阻塞合成线程下一帧 - 动画元素父容器设置了
overflow: hidden且自身发生位移，浏览器可能为裁剪而退回到CPU绘制路径 -
will-change: transform被静态写死在CSS中，大量元素长期占用合成层内存，在内存紧张的TV盒子或低端安卓设备上引发图层回收抖动
高刷屏下transition与@keyframes行为不一致
两者底层调度机制不同，对高刷适配能力有差异：
-
transition由样式变更触发，浏览器通常能较快响应高刷节拍，但transition-delay在高刷下可能被压缩或舍入（如设0.05s在120Hz下实际≈0.0417s或0.0833s） -
@keyframes若使用steps()或cubic-bezier(0,0,1,1)等非平滑缓动，容易因插值步长与高刷帧不匹配产生“粘滞感”；更稳妥的是用ease-out或自定义cubic-bezier(.25,.46,.45,.94)这类连续可导曲线 - 动画时长若为非整数毫秒（如
333ms），在120Hz（8.33ms/帧）下实际运行帧数为40.0，浏览器可能向下取整为40帧，造成末尾微顿
真正能稳住高刷动画的只有三件事
别指望加个will-change或换台新手机就能解决。必须同时满足：
- 动画属性严格限定在
transform和opacity范围内，@keyframes里连filter或box-shadow都不能混入 - 所有JS驱动的动画都用
requestAnimationFrame包裹，且读操作（如获取当前transform矩阵）与写操作（设置新transform）严格分离，中间不穿插DOM查询 - 在支持
matchMedia('(prefers-reduced-motion)')的环境里，也需监听screen.orientation或visualViewport变化，动态调整动画时长——高刷屏常伴随自动亮度/省电策略，这些系统级干预会悄悄降频合成线程
高刷屏的“掉帧”往往不是掉在渲染，而是掉在调度精度和系统干预的缝隙里。越想压榨帧率，越要放弃“写完就跑”的思路，把动画当成需要主动协程管理的实时任务来看待。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
