结论：不靠堆效果，靠分层策略和动态降级；通过“哪些动、怎么动、何时动”协同实现视觉酷炫与60fps兼顾，严格限定GPU友好属性动画，精准控制硬件加速、并发数量、设备适配及帧率节奏。
直接说结论：不靠堆效果，靠分层策略和动态降级。视觉酷炫和60fps不是非此即彼，而是通过“哪些动、怎么动、何时动”来协同实现。
只对 GPU 友好属性做动画
这是最硬的一条底线。任何用 top/left/width/height/margin 实现的位移或缩放，都会频繁触发重排（reflow），在中低端安卓机上一卡一个准。必须全部换成：
- transform: translateX/Y/Z、scale、rotate —— 移动、缩放、旋转全走合成层
- opacity —— 透明度变化由 GPU 独立处理，零重绘成本
- 禁用 filter（如 blur、drop-shadow）、box-shadow 动画——它们虽不重排，但大幅增加合成器负担，低端机极易掉帧
硬件加速要“精准开启”，不能全页加
给所有动效元素加 will-change: transform 或 transform: translateZ(0) 是常见误区。浏览器会为每个元素单独创建图层，内存暴涨，反而拖慢合成速度。
- 只对即将开始动画的元素提前 1 帧设置
will-change: transform，动画结束立即清除 - 对翻转类动画（如卡片 flip），iOS 上推荐加
backface-visibility: hidden，比 translateZ(0) 更稳 - 避免在父容器上盲目加加速——子元素动画已优化时，父层加速无意义，还可能引发图层合并失败
控制并发数量 + 懒加载触发
一个页面同时跑 8 个粒子动画 + 3 个视差滚动 + 全屏 SVG 路径动画，再好的写法也扛不住。关键不是“能不能做”，而是“要不要一起做”：
- 同一时间活跃动画建议 ≤ 3～5 个；复杂动效（如粒子、路径描边）优先降级为静态图或简化版
- 用 IntersectionObserver 替代 scroll 监听，让动画只在进入视口后才启动
- 首屏外的动效延迟加载，比如第二屏的渐入动画，等首屏渲染完成后再初始化
- 对低端设备主动识别（如 UA 包含 “Mi/Redmi”、“vivo Y”、“OPPO A” 或检测到
navigator.hardwareConcurrency ≤ 2），默认关闭非核心动效
用 requestAnimationFrame 控制节奏，不硬拼 60fps
追求绝对 60fps 反而容易翻车。真正目标是“感知流畅”——用户看不出卡顿，而不是仪表盘上死守 60。
- 所有 JS 动画必须用
requestAnimationFrame，禁用setTimeout(fn, 16)模拟帧率 - 复杂计算（如路径插值、数据映射）移到 Web Worker，主线程只负责 apply 样式
- 对高负载动画（如 Canvas 粒子、SVG 多路径同步），主动降为 30fps（每两帧更新一次），稳定性远高于强行 60fps 却频繁掉帧
- 监听
@media (prefers-reduced-motion: reduce)，对开启“减少动态效果”的用户，直接禁用所有非功能性动画
