H5端CSS动画卡顿主因是未触发GPU合成，须用transform/opacity并配合will-change、animation-fill-mode: forwards等优化措施，禁用left/top等触发重排属性及cubic-bezier等兼容性差的写法。
H5端CSS动画在特定机型（尤其是低端安卓、部分小米/华为机型）卡顿，根本不是“动画写得不够好”，而是浏览器渲染管线被阻塞或未触发GPU合成。关键在于：CSS动画本身没问题，但没跑在正确的渲染路径上。
为什么transform和opacity必须用，其他属性不行
Android WebView 和旧版 Safari 对 CSS 动画的硬件加速支持极不均衡。只有 transform 和 opacity 能稳定触发 GPU 合成；left、top、width、height、background-color 等会强制触发 Layout + Paint，主线程压力陡增。
- 错误写法：
animation: slideLeft 0.3s ease;配合@keyframes slideLeft { to { left: 100px; } }—— 在小米MIUI WebView中极易掉帧 - 正确写法：
animation: slideX 0.3s ease;配合@keyframes slideX { to { transform: translateX(100px); } } - 额外加固：给动画容器加
will-change: transform;（仅在动画触发前动态添加，结束后移除，避免长期占用GPU内存）
animation-fill-mode设错会导致跳帧或闪退
很多开发者设 animation-fill-mode: both; 想让动画结束态保留，但在部分低端安卓机型上，这会干扰浏览器对动画生命周期的判断，导致下一帧渲染延迟或直接丢弃最后一帧。
- 推荐组合：
animation-fill-mode: forwards;+ 动画结束时用 JS 显式设置最终样式（如el.style.transform = 'translateX(100px)';） - 绝对避免：
animation-fill-mode: backwards;—— 在 iOS Safari 中可能让元素初始状态不可见，首次触发动画时“突现” - 慎用
both：仅当动画需双向保持状态且已实测所有目标机型无异常时才启用
重复进入页面时动画不重放？别靠v-if销毁重建
H5内嵌页或Tab页切换后再次进入，mounted 不触发，CSS动画自然不会重播——这不是bug，是浏览器行为。强行用 v-if 销毁组件再重建，反而引发DOM重排+重绘，卡顿更明显。
立即学习“前端免费学习笔记（深入）”；
- 可靠方案：监听页面
onShow生命周期，在其中动态修改动画类名（如从animate-in→animate-in-trigger），利用 class 切换强制重触发 - 替代方案：用
key强制更新（如:key="tabIndex + Date.now()"），但仅限轻量组件，避免整页重渲染 - 禁用方案：不要用
document.body.style.display = 'none'; void document.body.offsetHeight; document.body.style.display = '';这种 hack——它会触发全局重排，比卡顿更伤性能
小米/华为机型特别卡？关掉transition里的cubic-bezier
部分国产定制WebView（尤其MIUI 13/EMUI 12）对复杂贝塞尔曲线解析存在兼容性缺陷，transition: all 0.3s cubic-bezier(0.25, 0.1, 0.25, 1) 可能被降级为线性过渡甚至失效，造成动画生硬或卡顿。
- 稳妥写法：
transition: transform 0.3s ease-out, opacity 0.3s ease-out;——ease-out兼容性远高于自定义贝塞尔 - 进阶控制：用
animation-timing-function: step-end;替代平滑过渡，适合“开关类”动画（如弹窗显隐），规避曲线解析问题 - 真机必测：在小米Note 10、华为Nova 7等典型机型上，用 Chrome DevTools 的 Rendering 面板开启 “Paint flashing”，观察是否出现大面积黄色重绘区块
真正决定卡不卡的，从来不是动画多炫，而是你有没有把 transform 写对位置、有没有让 will-change 只在需要时生效、有没有避开那些只在文档里写着“支持”，实际却在 MIUI 里静默失败的 CSS 属性。这些点漏掉一个，用户手指一划，卡顿就来了。
