应使用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，自动降级为基础动效模式