高刷新率屏幕需配合高效CSS属性才能发挥效果：translate和opacity因仅触发合成阶段而流畅，left等属性则因重排重绘导致掉帧；will-change是预加载提示而非加速开关；动画时长应缩至200–250ms并选用cubic-bezier缓动。
高刷新率屏幕（如 90Hz、120Hz）本身不会让动画“自动变流畅”，关键是你用的 CSS 动画属性是否能稳定输出对应帧率——否则浏览器仍按默认 60fps 节奏跑，空有硬件也白搭。
为什么 translate 和 opacity 能跑满高刷
高刷屏要求每帧渲染耗时更短（例如 120Hz ≈ 8.33ms/帧），而 transform 和 opacity 只触发布局流水线中的「合成」阶段，由 GPU 直接处理纹理位移或混合，不走主线程的 layout/paint，天然满足严苛时序。相反，left、width、background-color 每次变化都要重排重绘，一卡就是好几帧。
- 实测中，
transform: translateX(1px)在 120Hz 屏上可稳定维持 115+ fps；left: 1px同样动画常掉到 40–50fps - 注意：
scale和rotate同样高效，但避免和transform混用多个值（如同时写translateX+scale+rotate），会增加矩阵计算开销 - 低端 Android（如 Android 8 以下）对
transform: scaleZ(0)支持不稳定，优先用translateZ(0)或直接上will-change: transform
will-change 不是开关，是“预约单”
will-change 的作用不是开启加速，而是提前告诉浏览器：“接下来 1–2 帧内，这个元素的 transform 会变”。浏览器据此提前升层、预分配纹理内存。但它不解决动画逻辑本身的问题，滥用反而拖慢首帧。
- 正确做法：JS 中动画开始前设
el.style.willChange = 'transform'，在animationend或transitionend回调里立刻清空（el.style.willChange = ''） - 错误做法：全局给轮播容器加
will-change: transform，或长期保留在:hover伪类里 - 替代方案：对简单位移动画，
transform: translateZ(0)已足够触发升层，且无清除负担
动画时长和缓动必须匹配高刷节奏
60fps 下 300ms 动画看着自然，但在 120Hz 屏上会显得拖沓——因为帧数翻倍，人眼对节奏变化更敏感。不调整时长和缓动，等于浪费高刷能力。
立即学习“前端免费学习笔记（深入）”；
- 建议动画时长压缩到
200–250ms：既保留操作反馈感，又适配高刷帧间隔 - 避免
linear缓动：它在高刷下会暴露步进感；改用cubic-bezier(.25,.46,.45,.94)（即easeInOutCubic），起停更柔和 - 慎用
@keyframes中过多关键帧：每多一个to或from，浏览器就要插值计算一次，高刷下易累积误差；2–3 个关键帧通常够用
真正决定高刷屏上动画是否跟手的，不是“有没有用新属性”，而是“每一帧有没有把时间省下来”。删掉一个 box-shadow 动画、把 margin-top 换成 transform: translateY、在 JS 里少读一次 getBoundingClientRect()，这些细节叠加起来，才让 120Hz 从参数变成体感。
