顶层用 @for 或 @each 生成 @keyframes 必报错，因 CSS 要求关键帧名必须是静态字符串且 Sass 禁止顶层插值；必须封装进 @mixin 并显式 @include 调用，配合项目前缀、GPU 友好属性与模块化命名方可实现可维护动画。
直接在 SCSS 顶层用 @for 或 @each 生成 @keyframes 会编译失败——这不是写法问题，是 CSS 标准和 Sass 编译机制共同决定的硬限制。 必须把循环逻辑收进 @mixin，再显式 @include 调用，才能生成合法、可控、不冲突的关键帧规则。
为什么顶层循环写 @keyframes 一定报错
错误信息类似：Invalid CSS after "@keyframes slide": expected identifier, was "#{$i}"。根本原因有两点：
- CSS 标准要求
@keyframes名称必须是静态字符串，浏览器解析时不能做运行时插值 - Sass 编译器在顶层作用域禁止变量插值用于关键帧名，仅允许在
@mixin展开时通过#{$name}安全插值
试图绕过（比如用固定字符串拼接 slide-1、slide-2）会失去参数化能力，后续改动画节奏或位移量就得手动逐个修。
正确做法：用 @mixin 封装循环 + 显式调用
把动画逻辑封装进 mixin，每次 @include 都生成一组独立、命名唯一的关键帧：
- 名称必须带项目前缀，如
skeleton-shine-slow，避免全局冲突 - 所有数值（如
background-position、transform值）必须展开为静态值，不要在关键帧内用calc()或未定义变量 - 位移、时长、范围等应抽成 SCSS 变量，在 mixin 内部用
#{}插值，便于批量调整 - 例如生成三档扫光动画：
@include generate-skeleton-shine(slow 2s, medium 1.5s, fast 1s);
关键帧内容必须 GPU 友好，否则再“流畅”也掉帧
浏览器只对 transform 和 opacity 做合成层加速；一旦出现 left、top、width、height，就会触发重排重绘：
- 骨架屏动画务必用
background-position+transform: translateX模拟扫光，别用margin-left - 入场/滑入类动画只用
transform: translateY和opacity，禁用visibility或display切换 - IE11 降级方案需手动提供
opacityfallback，SCSS 循环无法自动生成兼容分支
最容易被忽略的命名和模块化陷阱
哪怕你用了 @use 和参数化 @mixin，只要关键帧名是 fade-in 这种通用名，就等于把隐患埋进 CI 流程里：
- 所有
@keyframes必须加项目前缀，如my-fade-in，不能靠文件路径隔离作用域 -
@use导入动画模块时，入口文件要透传前缀变量：@use 'animations' with ($prefix: 'my-'); - 别写
@mixin anim($value) { animation: $value; }—— 这等于放弃对关键帧内容的控制权，微调起始缩放值都得重写整个@keyframes
真正可维护的动画库，不是“生成得多”，而是“定义得稳、调用得准、改得少”。
