应使用 @media (prefers-reduced-motion: reduce) 直接重置动画属性，而非依赖 JS；需设 animation: none、transition: none、transform: none、opacity: 1 等并加 !important 确保生效。
如何用 @media (prefers-reduced-motion) 拦截动画
现代 CSS 动画（比如 transition、animation）在低端 Android 或旧款 iPhone 上容易掉帧、卡顿甚至白屏。最直接有效的拦截方式，是响应系统级的「减少动画」偏好设置——它不依赖 JS，不增加渲染负担，且被 Chrome、Safari、Firefox 全面支持。
关键不是“关掉所有动画”，而是“让浏览器知道：用户明确要求跳过动画”。系统开启该选项时，@media (prefers-reduced-motion: reduce) 会生效，此时你只需重置关键属性：
-
animation设为none，而不是0s或none 0s（后者仍可能触发解析开销） -
transition设为none，避免隐式过渡（如all 0.3s在低配机上仍会尝试计算） - 慎用
will-change：它在低配机上反而加重 GPU 压力，@media内应直接设为auto
示例：
button {
transition: background-color 0.2s, transform 0.2s;
animation: pulse 2s infinite;
}
@media (prefers-reduced-motion: reduce) {
button {
animation: none;
transition: none;
will-change: auto;
}
}为什么不能只靠 matchMedia + JS 控制
JS 检测 window.matchMedia('(prefers-reduced-motion: reduce)') 确实可行，但存在两个硬伤：
立即学习“前端免费学习笔记（深入）”；
- 首次渲染已完成：CSS 动画可能已在 DOM 加载后立刻触发（尤其内联样式或
<style>中定义），JS 注入晚于样式计算，拦不住首帧 - 运行时开销：需监听
change事件并批量操作 class 或 style，低端机上频繁 DOM 写入反而比纯 CSS 更卡 - 无法覆盖第三方库：比如某个 UI 组件库自带
fade-in动画，你 JS 无法安全 patch 它的<style>标签
结论：JS 只适合做兜底（比如动态加载的弹窗），核心拦截必须由 CSS 媒体查询完成。
哪些动画属性必须显式重置
很多人以为设了 animation: none 就万事大吉，但低配机对某些隐式动画行为依然敏感：
-
transform的scale/translate连续变化：即使没写transition，浏览器也可能启用合成层，吃内存 -
opacity变化：部分 Android WebView 对 opacity 动画优化极差，需配合will-change: auto -
filter（如blur(),drop-shadow()）：GPU 解码成本高，@media内建议直接设回none -
backdrop-filter：低端机基本不支持，强制关闭可避免渲染异常或白屏
实操建议：在 @media (prefers-reduced-motion: reduce) 块里，对所有含视觉渐变的元素统一加一层「降级规则」：
@media (prefers-reduced-motion: reduce) {
* {
animation: none !important;
transition: none !important;
transform: none !important;
opacity: 1 !important;
filter: none !important;
backdrop-filter: none !important;
}
}注意：!important 是必要的——它能压过组件库或内联 style 的权重，确保降级生效。
兼容性与真实设备验证要点
prefers-reduced-motion 在 iOS 10+/Android Chrome 79+ 均可用，但有两个易忽略的实际问题：
- iOS 设置路径深：设置 → 辅助功能 → 动作 → 减少动态效果（不是「降低透明度」！）；测试前务必手动打开，别信模拟器默认值
- 部分国产安卓定制系统（如 MIUI、EMUI）未透传该偏好，需 fallback：检测
navigator.userAgent包含Mobile且screen.width <= 480时，主动加一个.reduced-motionclass 到<html>，再写对应 CSS - 不要依赖
requestAnimationFrame节流动画：RAF 在低配机上本身就不准，且无法阻止初始帧渲染
最稳妥的验证方式：真机开启系统设置后，刷新页面，用 Chrome DevTools 的 Rendering 面板勾选「Emulate CSS reduced motion」交叉确认，再关掉模拟、切回真机看是否真正静止。
复杂点在于：动画降级不是开关题，而是分层决策——系统偏好是第一道闸，设备能力是第二道，而你写的 CSS 规则是否足够“暴力”（比如用了 !important 和通配符），决定了它能不能在那些连 will-change 都会崩的机型上真正停下来。
