prefers-reduced-motion 仅响应用户主动开启的“减少动画”偏好，与设备刷新率、GPU性能等硬件能力无关；它不感知高刷屏，也不能触发帧率适配，W3C 明确将其归为用户偏好而非性能信号。
不能靠 @media (prefers-reduced-motion: reduce) 优化高刷屏动画性能——它根本不管刷新率，只管用户是否主动要求“减少动画”。
为什么 prefers-reduced-motion 和高刷屏无关
这个媒体查询检测的是操作系统或浏览器设置里的「减少动画」开关（比如 macOS 的“减少运动”、Windows 的“显示设置→动画效果”、Android 的“动画缩放”），不是设备硬件能力。一台 120Hz iPad 可能开了 reduce，一台 60Hz 老安卓机可能全程开着动画但跑不动。W3C 明确把它归为“用户偏好”，和 screen.refreshRate 或 deviceMemory 这类性能信号完全不互通。
常见误用现象：
- 写了
@media (prefers-reduced-motion: reduce) { .hero { animation: slideIn 0.6s; } }，结果高刷屏用户没开 reduce，动画仍按 60fps 时间轴跑，帧率浪费 - 以为加了这个查询就能“自动适配高刷”，实际 Chrome 120+ 对
scroll-behavior: smooth的高刷支持是独立实现的，和该媒体查询毫无关系
真正影响高刷屏动画表现的是 CSS 属性选择和合成策略
高刷屏动画是否流畅，取决于两点：是否触发 GPU 合成、浏览器能否按真实刷新率调度帧。CSS 本身没有“声明刷新率”的能力，但你可以控制哪些属性能被高效合成：
立即学习“前端免费学习笔记（深入）”；
- 必须用
transform和opacity，禁用top/left/width等触发布局的属性——否则哪怕 240Hz 屏幕也会卡在 CPU 布局阶段 - 避免滥用
will-change: transform：它只是“预告”，不是加速器；对静态元素提前声明反而增加内存开销，尤其在低端 Android 上易引发图层爆炸 - 慎用
transform: translateZ(0)强制提升图层：现代浏览器已能智能判断合成时机，手动干预可能干扰默认优化逻辑
如何让动画在高刷屏上真正跑满帧率
目前没有纯 CSS 方案能显式绑定屏幕刷新率。可行路径是「CSS 定义动画结构 + JS 动态调控节奏」：
- 基础动画用
@keyframes写好，例如@keyframes fadeIn { from { opacity: 0; } to { opacity: 1; } } - 用
matchMedia('(prefers-reduced-motion: reduce)').matches判断是否跳过动画，而不是用来做性能分层 - 如需精细控制帧率，改用
requestAnimationFrame驱动element.animate()或element.style.transform，并参考window.devicePixelRatio（间接反映设备代际）做粗略 fallback，但不要依赖screen?.refreshRate——它在多数桌面浏览器返回0或undefined
最常被忽略的一点：动画卡顿往往不是因为“没适配高刷”，而是因为用了会触发布局的属性，或者在滚动容器里堆了太多 will-change。先确保 transform/opacity 路径干净，再谈刷新率优化。
