多个@keyframes可共存但元素仅能应用一个animation-name；需用逗号分隔多个名称实现叠加，且各子属性项数必须严格对应；transform函数顺序影响最终效果，合并写入同一句可实现复杂原子动画。
多个 @keyframes 可以共存，但一个元素只能用一个 animation-name
CSS 动画不支持单个 @keyframes 规则里写多套独立动画逻辑。所谓“多重关键帧”，实际是靠定义多个命名的 @keyframes，再通过 animation-name 指定其中一个——或者用逗号分隔多个名称，实现叠加播放。
常见误区是以为能在同一个 @keyframes slide-and-rotate 里分别控制位移和旋转的起止时间点，结果发现 transform 被后声明的覆盖（比如 rotate(360deg) 写在最后，前面的 translateX 就失效了）。
- 每个
@keyframes是一套独立的时间轴，不能“分支” - 想让平移和旋转节奏不同？必须拆成两个
@keyframes，再用两个元素或伪元素分别应用 - 用逗号写多个
animation-name（如animation-name: slide, pulse, fade;）时，浏览器会并行执行，但所有动画共享同一套animation-duration和animation-timing-function，除非显式分开写全量属性
animation 属性逗号分隔时，各参数必须一一对应
当用逗号叠加多个动画时，animation 的每个子属性（如 duration、delay、iteration-count）都按顺序匹配到同位置的动画名。错位会导致行为完全不可预期。
div {
animation-name: slide, rotate, blink;
animation-duration: 2s, 1.5s, 0.8s;
animation-delay: 0s, 0.3s, 0.6s;
animation-iteration-count: infinite, 3, 5;
}
上面这段代码中，slide 动画持续 2 秒、无延迟、无限循环；rotate 持续 1.5 秒、延迟 0.3 秒、执行 3 次；blink 持续 0.8 秒、延迟 0.6 秒、执行 5 次。少写一个值（比如只写 animation-duration: 2s, 1.5s;），第三个动画就会回退到默认值 0s，直接看不见。
立即学习“前端免费学习笔记（深入）”；
- 所有逗号分隔的动画，必须保证
animation-name和其余子属性的项数严格一致 - 推荐用完整简写
animation分开声明，避免歧义：animation: slide 2s, rotate 1.5s 0.3s, blink 0.8s 0.6s 5; - 注意
animation-fill-mode等非时间类属性也遵循同样映射规则
用 transform 合并操作时，顺序决定最终效果
即使只用一个 @keyframes，也能做出“多重关键帧感”的复杂运动——关键是把多个变换写进同一句 transform，并利用函数顺序影响合成结果。比如 translateX(100px) rotate(90deg) 和 rotate(90deg) translateX(100px) 效果完全不同。
@keyframes complex-move {
0% { transform: translateX(0) rotate(0) scale(1); }
50% { transform: translateX(200px) rotate(180deg) scale(1.2); }
100% { transform: translateX(0) rotate(360deg) scale(1); }
}
这个动画里，元素先向右移动、同时顺时针转半圈并略放大；再回到原点、继续转半圈、恢复大小。整个过程是原子性的，不会出现“先平移完再旋转”的断层感。
-
transform函数从左到右执行，前一个变换的坐标系会影响后一个（例如先rotate，再translateX就是沿旋转后的 X 轴移动） - 不要试图用多个
transform声明覆盖（如先写transform: translateX(100px);，再写transform: rotate(45deg);），后者会完全替换前者 - 需要动态组合？JS 中改
style.transform字符串时，务必拼接完整，不能只设一部分
性能敏感场景下，避免在关键帧里读写布局属性
动画期间频繁触发 offsetTop、getBoundingClientRect() 或修改 height/width 这类会引发重排（reflow）的操作，会让本该 60fps 的动画掉帧。尤其当多个动画叠加、或关键帧中嵌套 calc() + 百分比 + viewport 单位时，浏览器计算压力陡增。
- 纯
transform和opacity属于合成层属性，GPU 加速友好；其他属性（left、top、background-color）尽量不用在高频动画中 - 用
will-change: transform提前提示浏览器优化，但别滥用——对静态元素加这个反而降低性能 - 调试时打开 Chrome DevTools 的
Rendering > FPS Meter和Layers面板，确认动画是否真走上了合成器
真正复杂的动画往往不是靠堆砌关键帧数量，而是靠分层、错帧、合理利用 transform 顺序和硬件加速边界。细节一旦漏掉，比如某个 animation-delay 少写了一个单位，或者 transform 里函数顺序反了，整个节奏就崩了。
