低端安卓机CSS3动画卡顿主因是触发重排，仅transform和opacity可保60fps；transition和@keyframes中须独用二者；will-change需JS动态控制；动画中禁读布局信息。
低端安卓机（尤其是 Android 5–7 WebView）上 CSS3 动画卡顿，基本不是“没开硬件加速”，而是你动了 top、left、width、height 这类属性——它们一改就触发重排，主线程直接堵死。真正能稳住 60fps 的，只有 transform 和 opacity。
transition 中只写 transform，别混其他属性
常见错误是写 transition: all 0.3s 或 transition: left 0.3s, opacity 0.3s，哪怕只混进一个非合成属性，整条过渡都会降级回 CPU 渲染。
- ✅ 正确写法：
transition: transform 0.3s cubic-bezier(0.25, 0.46, 0.45, 0.94) - ✅ 同时位移+缩放？仍只写
transform：它本身是单一属性，内部translate、scale共享同一过渡逻辑 - ❌ 绝对不要：
transition: left, transform 0.3s——left会让浏览器放弃图层优化 - ⚠️ 注意：Android 5–7 WebView 对
cubic-bezier()支持良好，但别用steps()或自定义贝塞尔超出范围（如 y > 1）
@keyframes 里只留 transform 和 opacity
浏览器不会报错，但只要关键帧里塞进一个 margin、box-shadow、background-color，整段动画就默默退回 CPU 渲染，帧率掉得无声无息。
- ✅ 安全写法：
@keyframes slide { from { transform: translateX(-100%); opacity: 0; } to { transform: translateX(0); opacity: 1; } } - ✅ 文字颜色渐变？别用
color动画，改用两层文字叠一起，靠opacity切换显隐 - ❌ 删掉所有：
width、height、border-radius（尤其和transform混用时）、filter - ? 关键帧尽量压缩：从
0% → 25% → 50% → 75% → 100%简化为0% → 100%，减少计算负担
will-change 必须动态控制，不能静态写死
will-change: transform 不是保险丝，而是定时器——设早了浪费内存，设晚了起不到作用。静态写在 CSS 里（比如 .list-item { will-change: transform; }），在低端机上极易图层爆炸、OOM 卡死。
立即学习“前端免费学习笔记（深入）”；
- ✅ JS 中动态加：
el.style.willChange = 'transform'，时机选在touchstart或mouseenter后、动画 class 添加前那一帧 - ✅ 动态删：监听
transitionend或animationend后立刻执行el.style.willChange = 'auto' - ⚠️ iOS Safari 对 ≤16ms 动画可能不触发
animationend，务必加兜底：setTimeout(() => el.style.willChange = 'auto', duration + 100) - ❌ 禁止批量设：列表页 20 个卡片，千万别统一加
will-change，宁可不用也不图层爆炸
动画过程中 JS 绝对不能读取布局信息
这是最常被忽略的掉帧元凶。哪怕只是调一次 getBoundingClientRect()、offsetHeight 或 getComputedStyle()，也会强制同步 layout，直接破防。
- ✅ 所有读操作必须前置：动画开始前一次性获取并缓存，比如
const rect = el.getBoundingClientRect()存变量里 - ✅ 或延后到
animationend之后再读 - ❌ 禁用：
offsetTop、clientWidth、scrollHeight、任何带 “offset”/“client”/“scroll” 的 API - ⚠️ 特别注意：Vue/React 中
ref.value.offsetHeight在useEffect或mounted里读没问题，但在requestAnimationFrame动画循环里读就是雷区
真正难的不是写对 transform，而是守住边界：不混属性、不静态加 will-change、不偷偷读布局。这些点漏掉任何一个，60fps 就只是幻觉。
