移动端必须用@media (prefers-reduced-motion: reduce)而非JS，因iOS Safari和Android WebView存在偏好信号延迟或漏触发问题；CSS媒体查询原生监听、样式计算阶段即生效，可拦截首帧动画及第三方组件内联样式。
移动端必须用 @media (prefers-reduced-motion: reduce)，不能靠 JS 初始化时判断一次就完事——iOS Safari 会延迟触发、Android WebView 可能漏掉首次渲染。
为什么移动端特别依赖 CSS 媒体查询而不是 JS
在 iOS 和部分 Android WebView 中，window.matchMedia('(prefers-reduced-motion: reduce)') 的 matches 值可能在页面加载完成前为 false，即使系统已开启「减少动态效果」。这是因为 WebKit 内核对偏好信号的透出有延迟，而 CSS 媒体查询是渲染引擎原生监听的，从样式计算阶段就生效。
- 首次渲染动画（比如
.modal.fade-in内联定义的animation）JS 来不及拦截 - 第三方 UI 库（如 Ionic、Vant）的组件自带
<style></style>标签，JS 无法安全 patch - 滚动锚点、
:focus-within触发的过渡也绕过 JS 控制流
如何写真正生效的移动端 reduced-motion 规则
只写 animation: none 不够，移动端 WebView（尤其是旧版 Android System WebView）对隐式合成行为仍敏感。必须显式归零所有可能触发插值的属性，并加 !important 确保覆盖内联样式或高优先级选择器。
- 用
animation: none !important，别写animation: none 0s（后者仍会解析时长） - 用
transition: none !important，避免transition: all 0.2s这类宽泛声明残留副作用 - 对含
transform或opacity的交互元素，额外加will-change: auto !important - 慎用
@keyframes名称重置（如animation: spin 0s），某些 Android 7.x WebView 会误判为有效动画
示例：
立即学习“前端免费学习笔记（深入）”；
button {
animation: bounce 1s ease;
transition: opacity 0.3s, transform 0.3s;
will-change: transform;
}
@media (prefers-reduced-motion: reduce) {
button {
animation: none !important;
transition: none !important;
will-change: auto !important;
}
}
移动端调试与兼容性注意点
Safari on iOS 13+、Chrome for Android 80+、Firefox for Android 68+ 都支持 prefers-reduced-motion: reduce，但行为细节不同：
- iOS Safari 对自定义滚动条、
backdrop-filter动画也会静音，无需额外处理 - 部分 Android 9/10 系统 WebView 不响应
no-preference，只认reduce，所以不要写@media (prefers-reduced-motion: no-preference)做“开启动画”的兜底 - 真机调试时，必须在系统设置里开关「减少动态效果」，DevTools 的 Rendering 面板模拟仅对桌面 Chrome 有效
- 微信内置浏览器（X5 内核）目前不支持该媒体查询，需用 JS + class fallback 双保险
最易被忽略的是：动画禁用后，交互反馈不能消失。比如按钮点击态要保留 :active 背景色变化，只是去掉 transform: scale()；轮播图要提供手动翻页按钮，而不是直接变静态图——用户需要知道“还有内容”，只是不自动动。
