高刷屏下CSS动画卡顿本质是时间步长未对齐设备刷新率，浏览器仍按60fps（16.67ms）计时，而非90Hz（11.1ms）或120Hz（8.3ms）；需用requestAnimationFrame手动插值并按screen.refreshRate动态计算帧间隔。
移动端高刷新率屏幕（如 90Hz、120Hz）下，CSS 动画默认仍按 60fps 渲染，导致动画“卡顿感”或“不跟手”，本质不是帧率不够，而是时间步长没对齐——浏览器仍在每 16.67ms 走一帧，而屏幕期待每 11.1ms（90Hz）或 8.3ms（120Hz）更新一次。
为什么 transition 和 @keyframes 在高刷屏上会掉帧？
浏览器的 CSS 动画计时器目前不自动适配设备刷新率。即使设备支持 120Hz，transition: transform 300ms 仍被拆成约 18 帧（300 ÷ 16.67），而非 36 帧（300 ÷ 8.3）。结果是：动画逻辑完成得早，但视觉上出现“停顿”或“跳变”，尤其在快速拖拽、滚动联动类动画中明显。
- Chrome Android（截至 2026 年 10 月）尚未启用
prefers-reduced-motion或screen.refreshRate的 CSS 原生适配 -
requestAnimationFrame虽能获取真实帧时机，但纯 CSS 动画无法接入该回调 - 使用
animation-timing-function: steps(30, jump-end)等强行分帧，反而因 JS/CSS 同步延迟加剧抖动
用 will-change + transform 组合无法解决高刷匹配问题
will-change: transform 只影响图层创建策略，不改变动画插值节奏；它解决的是“是否走合成线程”，而非“多久走一帧”。加了它，动画依然按 60fps 时间轴执行，在 120Hz 屏上表现为前半段快、后半段粘滞。
- 错误做法：
.slider { will-change: transform; animation: slide 300ms ease-out; }—— 图层升了，但帧间隔还是 16.67ms - 真正需要的是：让动画持续时间与设备刷新周期对齐，且关键帧生成足够密
- iOS Safari 对高刷适配更差：即使
requestAnimationFrame回调频率提升，transitionend事件仍常在第 16ms 才触发，造成 JS 清除will-change延迟
实操方案：用 requestAnimationFrame 驱动关键位移 + transform 插值
绕过 CSS 动画计时器限制，手动控制每一帧的 transform 值，确保在 120Hz 设备上每 ~8.3ms 更新一次。适用于手势驱动、滚动视差、进度指示器等对响应精度要求高的场景。
立即学习“前端免费学习笔记（深入）”；
- 第一步：用
screen?.refreshRate检测（仅部分 Android Chrome 支持）， fallback 到window.matchMedia('(motion: reduce)').matches ? 60 : 120 - 第二步：计算目标帧间隔：
const frameMs = 1000 / Math.min(120, refreshRate || 60) - 第三步：在
raf循环中线性插值：el.style.transform = `translateX(${ease(t) * finalX}px)`，其中t = Math.min(elapsed / duration, 1) - 关键点：首帧必须立即设
will-change: transform，最后一帧清空（用setTimeout兜底，因animationend不可靠）
let startTime = 0;
function animate(timestamp) {
if (!startTime) startTime = timestamp;
const elapsed = timestamp - startTime;
const t = Math.min(elapsed / 300, 1);
const x = easeOutCubic(t) * 200; // 替换为你的缓动函数
el.style.transform = `translateX(${x}px)`;
if (t < 1) requestAnimationFrame(animate);
else el.style.willChange = 'auto'; // 必须清
}哪些动画可直接保留 CSS，无需重写？
非交互式、低频、非精确时序依赖的动画（如加载骨架、模态框淡入）仍可用原生 CSS，但需规避两个陷阱：
- 禁用
transition: all，明确只写transition: transform 300ms, opacity 300ms，避免隐式触发布局属性 - 避免在
@keyframes中混用transform和filter/box-shadow—— 即使高刷下，这类属性仍强制回退到 CPU 渲染，帧耗飙升至 20ms+ - 对轮播图等定时动画，把
animation-duration改为250ms（适配 120Hz 下约 30 帧），比硬套 300ms 更顺滑
高刷屏的动画优化，核心不在“加速”，而在“对齐”——时间粒度要匹配硬件，图层策略要克制，JS 控制权该交还时就交还。最易被忽略的是：iOS Safari 的 requestAnimationFrame 在后台标签页或低电量模式下会降频，此时你写的 120Hz 动画可能实际跑在 30fps，得靠 performance.now() 差值动态调整帧间隔。
