mui-queue 的延迟值必须为字面量或已求值变量，不可用循环变量动态计算；动态延迟应改用 css 自定义属性与 calc()；关键帧参数须统一收进 map 管理，命名需语义化且固定，避免拼接导致缓存失效与命名冲突。
用 mui-series 和 mui-queue 编排元素入场顺序
直接套用 mui-series 就能形成时间错位的级联动画，但关键在延迟值是否可维护。它不接受动态计算的延迟（比如 $i * 0.1s），所有 mui-queue 的第二个参数必须是字面量或已求值变量。
- 写法正确：
@include mui-queue(0.4s, 0.2s, fade-in) - 写法危险：
@include mui-queue(0.4s, $base-delay + $i * 0.1s, slide-up)—— Sass 编译期无法在 mixin 内部对循环变量插值 - 若需动态延迟，改用 CSS 自定义属性 +
@keyframes中 calc()，Sass 只负责生成初始类名和基础帧
动画时序参数必须统一收进 map，否则关键帧与声明必然脱节
常见翻车是只改了 animation 属性里的 duration，却忘了关键帧内部的 opacity 过渡节奏也依赖该值——结果视觉节奏断裂，像卡顿两帧。
- 错误模式：独立变量
$fade-duration: 0.3s+ 硬编码关键帧0% { opacity: 0; } 100% { opacity: 1; } - 正确模式：用
$anim-seq: ("fade": (duration: 0.3s, easing: ease-out))，关键帧里虽不能调map-get()，但至少声明层和调用层共用同一份数据源 - 真正要让关键帧响应变量，得靠
@content+ 手动传入帧逻辑，Mixin 只管命名和包裹
避免用参数拼接 @keyframes 名称，全局命名空间极易冲突
像 in-anim-#{$duration}-#{$easing} 这种拼接看似复用，实则埋雷：两个组件分别传 0.3s 和 300ms，编译后生成两个不同名称的关键帧，但浏览器认为它们是独立动画，无法共享缓存，还可能因命名过长触发 CSSOM 限制。
- 安全做法：每个 mixin 固定一个语义化名称，如
fade-in-anim、slide-up-anim - 想区分变体？靠 class 名控制，比如
.fade-in--fast改animation-duration，而非生成新关键帧 - Sass 不支持局部作用域关键帧，所有
@keyframes都挂载在全局，命名必须唯一且稳定
分离 animation-name 和 animation-delay 是调试复杂序列的底线
复合写法 animation: fade-in 0.3s ease 0.1s 看似简洁，但只要某处只覆盖其中一项（比如 hover 时只写 animation: fade-in 0.2s），其余项就会回退到初始值，导致原本设定的 0.1s delay 消失，整个序列错位。
- 推荐写法：
animation-name: fade-in; animation-duration: 0.3s; animation-delay: 0.1s; - 这样 JS 或状态类切换时，可以精准覆盖某一项，不影响其他时序逻辑
- 尤其在 Vue/React 的 enter/leave 钩子中，
transition: none必须加在-active类里，否则 CSS 动画会和 JS 生命周期抢帧
实际项目里最易被忽略的是：关键帧内部无法读取 Sass map 变量，所以“参数驱动关键帧节奏”本质是个伪需求；真正可控的只有声明层的时长、延迟、贝塞尔曲线，以及通过 @content 手动注入的帧逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
