低端手机掉帧主因是浏览器每帧触发layout/paint致CPU满载，须锁定GPU合成层：仅用transform/opacity动画，禁用left/top等非合成属性，精简关键帧，合理使用will-change，响应prefers-reduced-motion降级。
低端手机掉帧，根本不是“动画太 fancy”，而是浏览器每帧都在做 layout 或 paint——这两个阶段全靠 CPU，而低端机的 CPU 一碰就满载。必须把动画路径锁死在 GPU 合成层里，其他路一律堵死。
只用 transform 和 opacity 做动画
这两类属性是唯二能全程走合成线程的 CSS 属性，不触发重排（reflow）也不触发重绘（repaint）。一旦混入 left、top、width、box-shadow 或 filter，整条流水线立刻退回到主线程。
-
left: 50px→ 改为transform: translateX(50px)；需要强 GPU 提示时，用transform: translate3d(50px, 0, 0) -
opacity可以和transform安全共存，但别加visibility: hidden或display: none到同一过渡中 - 动画中读取
getBoundingClientRect()、offsetHeight或写style.width，哪怕只调一次，也会强制同步 layout，直接破防
@keyframes 里删掉所有非合成属性
关键帧不是越细越好，而是越“干净”越稳。低端机扛不住样式计算开销，更扛不住 layout/paint 的反复触发。
- 禁用：
width、height、margin、padding、border-radius（尤其配合transform动画时）、box-shadow的blur-radius或spread-radius - 简化帧数：从 0% → 25% → 50% → 75% → 100% 压缩为 0% → 100%，用
cubic-bezier(0.34, 1.56, 0.64, 1)替代ease-in-out，降低首尾帧计算压力 - 避免在
@keyframes里写!important或含calc(100vw - 20px)这类表达式，部分 Android WebView 解析慢且易出错
will-change 不是开关，是定时器
静态写 will-change: transform 在 CSS 里，等于让浏览器永远给这个元素建独立图层——内存涨、上下文切换多、滚动反而卡。它只对“即将动”的元素有效。
立即学习“前端免费学习笔记（深入）”；
- 动画开始前 1–2 帧用 JS 设置：
el.style.willChange = 'transform' - 监听
animationend或transitionend后立刻清除：el.style.willChange = 'auto' - iOS Safari 可能不触发
animationend，务必加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - 别对列表项批量设
will-change，安卓低端机容易 OOM；优先用transform: translateZ(0)这类轻量级升层方式
用 @media (prefers-reduced-motion) 主动降级
这不是“照顾残障用户”的可选项，而是识别低配设备最准的信号——系统级设置开启时，大概率是旧款 iPhone 或千元安卓机。JS 检测 UA 或性能 API 都不如它可靠。
- 必须设
animation: none !important，不是animation-duration: 0s（后者仍会解析） - 连带清空：
transition: none !important、transform: none !important、opacity: 1 !important - 别在里面写
will-change: auto——will-change在低配机上反而加重 GPU 压力，直接忽略即可
真正顺滑的前提，不是“用了 translate3d”，而是整条渲染路径里没有任何一个环节偷偷摸摸触发了 layout 或 paint——哪怕只有一帧，都会让 GPU 合成线程等在那儿，帧就掉了。
