animate.css需手动控制多阶段动画时序，正确做法是用javascript逐个添加类名并确保包含animate__animated基类，避免同时添加多个动画类导致冲突。
直接用 Animate.css 处理多阶段入场动画
Animate.css 不是“开箱即用就自动连播”的工具，它默认只触发单次动画。想实现「先淡入、再上滑、最后缩放」这类序列，必须手动控制类名添加时机，否则所有动画会同时开始、互相覆盖。
常见错误是这样写：<div class="animate__fadeIn animate__slideInUp animate__zoomIn">——三个类同时生效，浏览器按自身规则叠加，结果不可控，且无法设置各阶段延迟。
<ul>
<li>正确做法是用 JavaScript 控制类名逐个添加，例如用 <code>setTimeout 或 Promise 链
animate__animated 才生效，漏掉这个基类会导致无效果animation-fill-mode: backwards，所以元素在动画开始前会保持初始状态；若需“动画结束后保留最终样式”，得额外加 animate__animated animate__fadeIn animate__fadeIn--delay-1s 这类修饰类，或手动补 animation-fill-mode: forwards
用 CSS 自定义属性 + @keyframes 组合长序列
当动画逻辑强依赖状态（比如加载中 → 成功 → 错误 → 重试），硬编码多个 @keyframes 并用 JS 切换 class 容易失控。更稳的方式是把动画拆成原子级片段，用 CSS 变量驱动流程。
例如定义一个基础动画容器：
.sequence-trigger {
--anim-step: 0;
animation: sequenceRunner 1ms steps(1, end);
}
@keyframes sequenceRunner {
0% { --anim-step: 0; }
100% { --anim-step: 1; }
}
再配合属性选择器分别响应不同步骤：
[data-step="0"] { opacity: 0; transform: translateY(20px); }
[data-step="1"] { opacity: 1; transform: translateY(0); }
[data-step="2"] { transform: scale(1.05); }
JS 只需改 data-step 属性值，CSS 自动匹配对应状态。这种方式避免了 class 名冲突、时序错乱，也方便后续用 transition 补平滑过渡。
避免在复杂序列里滥用 will-change
will-change 不是性能银弹，尤其在多阶段动画中滥用反而拖慢渲染。它告诉浏览器“这个元素即将变化”，但浏览器为此要提前创建合成层——如果几十个元素都设 will-change: transform，图层数量爆炸，内存占用飙升，低端设备直接卡顿。
- 只对真正高频变化的元素（如滚动区域内的浮动按钮）设
will-change - 动画结束后记得清除：用 JS 在
animationend事件里移除该声明，或用transition配合transform: none回退 - 优先用
transform: translateZ(0)或transform: translate3d(0, 0, 0)触发硬件加速，比will-change更轻量、更可控
用 Web Animations API 衔接 JS 控制力与 CSS 性能
CSS 类库处理不了的动态节奏（比如根据 API 响应时间调整动画时长），就得切到 JS 层。但别手写 requestAnimationFrame ——直接用 Element.animate()，它复用 CSS 动画引擎，性能不输纯 CSS，还能实时读写当前播放进度。
示例：根据后端返回的 duration 字段动态生成动画：
element.animate([
{ opacity: 0, transform: 'scale(0.8)' },
{ opacity: 1, transform: 'scale(1)' }
], {
duration: response.duration || 300,
easing: 'cubic-bezier(0.25, 0.46, 0.45, 0.94)',
fill: 'forwards'
});
关键点：
-
fill: 'forwards'确保动画停在终点，否则元素会回退到初始状态 - 传入的 keyframe 数组必须是纯对象，不能含 CSS 单位以外的计算（如
calc()） - 若需暂停/恢复，用
animation.pause()和animation.play()，比 class 切换更精确
真正麻烦的不是写几段动画，而是让它们在不同设备、不同网络条件下都保持可预期的节奏和终止状态。多数人卡在“看起来动了”，却没验证动画是否真在 60fps 下稳定运行，也没考虑降级方案——比如 Safari 对 animation-composition 支持弱，某些组合动画会直接失效。这些细节不测到真机，光看 Chrome DevTools 的 FPS 曲线没用。
