应使用requestAnimationFrame绑定真实刷新节奏，结合prefers-reduced-motion降级、transform/opacity硬件加速及运行时能力检测动态适配动效。
移动端网页动效要真正适配屏幕刷新率，不能只靠“猜”或“估”，得让动画节奏和设备能力对齐。高刷屏（如120Hz）用户期待更顺滑的反馈，而低刷屏（60Hz甚至更低）或性能受限设备若强行跑高帧率动画，反而会掉帧、卡顿、发热耗电。关键不是统一设成60fps，而是让动效“知进退”——该快时快，该简时简。
用 requestAnimationFrame 绑定真实刷新节奏
别再用 setTimeout 或固定间隔的 setInterval 驱动动画。rAF 会自动匹配当前屏幕的刷新率：在120Hz设备上每约8.3ms触发一次，在60Hz设备上则是约16.7ms。它不只是“更准”，更是浏览器调度机制的一部分，能被系统级节流（比如页面切后台时自动暂停）。
- 所有 JS 动画逻辑（比如滚动视差、拖拽跟随、自定义进度条）都应封装在 rAF 回调中
- 避免在单次 rAF 中做大量计算；可拆分任务，用
queueMicrotask或分帧处理防阻塞 - 注意：rAF 不保证“一定执行”，需配合时间戳判断是否跳帧（例如用
performance.now()记录上一帧时间，动态调整插值步长）
结合 prefers-reduced-motion 主动降级动效层级
这不是“关动画”，而是按用户偏好重设动效语义。系统开启“降低动态效果”时，说明用户对运动敏感、关注续航，或依赖辅助技术。此时应：
Wechat Article Html
下载
将 Markdown 文章转换为微信公众号兼容的纯 HTML 格式。当用户要求"转成微信格式"、"生成公众号文章 HTML"、"排版到微信草稿箱"、"微信粘贴格式"时触发。输出带内联样式的纯 HTML，微信编辑器可直接渲染，无需额外适配。支持标题、段落、列表、粗体、行内代码、表格、引用块、代码块、配图的完整转换。
- 将淡入/缩放/位移类动画直接设为瞬间切换（
transition-duration: 0.01ms !important），避免残留过渡 - 把多阶段动效（如菜单展开+背景模糊+遮罩渐显）简化为单步状态切换
- 保留必要反馈，比如按钮点击的微反馈（
scale(0.98)）可保留，但去掉延迟、缓动和二次弹跳
用 CSS will-change 和 transform 触发合成器加速
浏览器只有把动画属性交由独立合成线程处理，才能避开主线程卡顿影响帧率。确保：
- 动画只使用
transform（translate、scale、rotate）和opacity，这两类属性不触发布局与重绘 - 对频繁动画的元素提前声明
will-change: transform, opacity，提示浏览器预分配图层（但别滥用，仅限真正持续动画的元素） - 避免用
top/left或width/height驱动动画——它们强制触发 layout，高刷下极易掉帧
运行时检测设备能力，动态调整动画复杂度
光靠媒体查询不够，有些中低端机虽支持 120Hz 显示，但 GPU 带不动多层滤镜叠加。可轻量检测：
- 用
navigator.hardwareConcurrency判断逻辑核心数（≤4 通常为中低端） - 监听
resize和orientationchange，在小屏或横屏时简化动效密度（比如关闭非关键视差） - 首次加载后用空 canvas +
getContext('2d')测绘图帧率，若连续3帧渲染超 25ms，自动降级为基础动效模式
