CSS动画流畅的关键是仅触发Composite阶段，必须使用transform和opacity属性，避免触发Layout和Paint；will-change需动态添加与清除，高刷屏适配本质是确保每帧≤8.3ms。
不需要“开启120Hz支持”——CSS本身没有开关能启用或禁用高刷屏，浏览器也不会因为你写了某个属性就自动把动画从60fps拉升到120fps。
为什么animation-duration设成0.5s在120Hz屏上还是卡顿
帧率不是由CSS时间值决定的，而是由浏览器能否在每帧8.3ms内完成渲染决定的。哪怕你写animation-duration: 0.1s，只要动画触发了布局（比如改top）、绘制（比如改background-color）或主线程被JS阻塞，实际帧率就会掉到30fps甚至更低。
- 浏览器不会“加速”你的动画；它只会在每帧调度时尝试执行一次关键帧计算+合成
-
@keyframes里的时间轴是逻辑时间，不是物理帧节奏——120Hz下每帧更短，但CSS不自动重采样关键帧 - 常见误判：以为把
transition-duration从300ms改成150ms就能适配120Hz，结果只是让动画变快了，没变顺
transform和opacity为什么是唯一靠谱的选择
只有这两个属性能绕过Layout和Paint阶段，直接进Composite（合成）管线——这是GPU能真正按120Hz节奏吞吐的唯一通路。
- 改
left/width/height→ 触发Layout → 主线程计算几何 → 必然掉帧 - 改
color/box-shadow/border-radius→ 触发Paint → 光栅化耗时不可控 → 高刷下更容易堆积 -
transform: translateX(100px)和opacity: 0.5→ 只更新图层矩阵和混合参数 → GPU直接接管 → 帧率稳定
will-change不是加速器，而是风险提示器
它告诉浏览器“这个元素接下来要动”，提前分配图层；但它不解决性能问题，反而可能引发副作用。
立即学习“前端免费学习笔记（深入）”；
- 对静态元素提前写
will-change: transform→ 浏览器会强制升层 → 内存占用翻倍，低端Android易OOM - 动画结束后没清除
will-change→ 图层常驻 → 滚动时额外合成开销 → 实际帧率反而下降 - 真正该做的：只在动画开始前一帧动态加
will-change，动画结束回调里立刻移除
高刷屏下最易被忽略的陷阱：滚动与scroll-behavior: smooth
这个属性在Chrome 120+中确实会响应120Hz刷新率，但前提是：没被@media (update: fast)误判干扰、没和prefers-reduced-motion冲突、且页面没触发强制同步布局。
-
@media (update: fast)不是设备检测，而是系统策略信号——省电模式、后台标签、GPU温度高都会让它返回slow -
prefers-reduced-motion完全无关刷新率，开了它只会停动画，不会降帧率 - 真正影响滚动流畅度的是
contain: layout paint和overscroll-behavior这类隔离策略，而不是媒体查询
高刷屏的“适配”本质是剔除所有非合成路径，把动画彻底交给GPU调度——这和写多少行CSS无关，而取决于你有没有让每一帧都落在8.3ms的硬约束里。
