backface-visibility: hidden仅解决动画过程中的图层抖动，不防止结束回跳；后者需animation-fill-mode: forwards配合完整100%关键帧及无高权重样式覆盖。
backface-visibility: hidden 是最该优先尝试的修复手段，但它只管动画过程中的图层稳定，不解决动画结束回跳——后者得靠 animation-fill-mode: forwards。
为什么加 backface-visibility: hidden 还是闪？
常见错误是把它加在父容器上，或者以为它能锁住动画终态。实际上：
-
backface-visibility不继承，必须直接写在「正在做transform或animation的元素」上，比如.slide、.card - 它只强制创建独立合成层，防止 Safari/旧 Android WebView 在过渡中反复丢弃重建图层——对应的是动画“进行中抖动”“白边闪烁”，不是“一停就跳回原样”
- Android 4.4–5.1 中反而可能因该属性抑制图层创建，此时要禁用它，改用 JS 动态注入
transform: translate3d(0,0,0)和will-change: transform - 别和
filter、mask、overflow: hidden同时用，这些在旧 WebView 里会强制降级到 CPU 渲染
animation-fill-mode: forwards 才管动画结束不闪
动画一停就抽搐、回跳、透明度归零？这不是图层问题，是浏览器默认把样式“撤回”。
- 必须显式声明
animation-fill-mode: forwards，或写进animation简写里：animation: slideIn 0.3s ease forwards -
@keyframes的100%帧必须完整定义终态，包括所有参与动画的属性（opacity、transform），且单位、空格、顺序要和元素默认值一致 - 内联样式（如
style="opacity: 0"）或高权重 CSS 类会直接覆盖forwards锁定的终态，导致失效 -
forwards只对“已成功执行完”的动画生效；如果 JS 刚加 class 就立刻 remove，或频繁切换animation-play-state，动画根本没走到结束，它就不起作用
低版本 Android（2.2–4.4）的特殊坑
这些系统里 WebKit 对 transform 解析极不稳定，尤其混用 translate 和 scale 时。
- 避免静态写死
translate3d(0,0,0)：会导致图层爆炸，Android 5–7 出现内存溢出、滚动卡顿 - 动画只是
opacity变化时，加translate3d毫无意义，纯增内存开销 - 真正需要时（如 Android 5–7 入场首帧明显卡顿），应在
animationstart事件中动态添加transform: translate3d(0,0,0)，并在animationend后立即移除 -
transform属性顺序很关键：Android 2.2 上scale(1.2) translateX(20px)比translateX(20px) scale(1.2)更稳；matrix()在 Froyo 上基本不可靠
别忽略 steps() 动画的闪动
用 steps(4, end) 做逐帧动画却出现跳帧或撕裂？这通常不是渲染问题，而是步进数与实际帧率不匹配。
立即学习“前端免费学习笔记（深入）”；
- 先确认动画持续时间是否合理：
animation-duration: 0.4s配steps(4)理论每帧 100ms，但低端设备未必能稳定输出 - 改用
linear缓动看是否消失；若仍闪，说明是合成层未就绪，此时才考虑加backface-visibility: hidden或动态translate3d -
steps()在 Android 4.0–4.3 中兼容性差，部分机型会降级为ease，建议 fallback 到 JS 控制帧
backface-visibility: hidden 和 animation-fill-mode: forwards 往往要一起用，但它们解决的是两类完全不同的“闪”——前者防过程抖动，后者锁终态表现。最容易被忽略的是：动画还没跑完就被 JS 干掉，forwards 根本没机会生效。 
