用SCSS变量控制@keyframes参数、预定义通用动画mixin、错开animation-delay，即可实现轻量可维护的骨架屏动画；直接复制硬编码关键帧会导致时长难统一、节奏难适配、降级无fallback三大问题。
直接说结论：用 SCSS 变量控制 @keyframes 参数 + 提前定义通用动画 mixin + 每个骨架项错开 animation-delay，就能在不写重复 CSS 的前提下，做出轻量、可维护、视觉真实的骨架屏动画。
为什么不能直接 copy-paste 网上 skeleton-loading 关键帧
多数公开代码把 @keyframes skeleton-loading 写死在样式里，比如 left: -100% 和 1.5s 硬编码。这导致三个实际问题：
- 改一次动画时长，要全局搜索替换所有
1.5s，容易漏掉伪元素或子组件里的引用 - 不同模块（列表项、卡片、头像）需要不同扫光速度，但共用同一套关键帧，只能靠覆盖
animation-duration，而浏览器会忽略对@keyframes内部值的变量注入 - IE11 不支持
background-position动画降级时，没法一键切到opacity方案——因为关键帧没预留 fallback 分支
SCSS 变量怎么真正驱动 keyframes（不是只改 duration）
关键在于：把关键帧逻辑抽成 @function 或 @mixin，再用 #{} 插值生成动态规则。例如扫光动画的核心位移范围：
@function skeleton-shine-offset($range: 200%) {
@return (-#{$range} 0, #{$range} 0);
}
<p>@keyframes skeleton-shine {
0% { background-position: #{skeleton-shine-offset(200%)}; }
100% { background-position: #{skeleton-shine-offset(200%)}; }
}
这样后续只需改 $range 变量，就能统一调整“光条宽度”和“扫过距离”，不用碰关键帧内部数值。同时配合根变量：
立即学习“前端免费学习笔记（深入）”；
:root {
--skeleton-shine-speed: 1.8s;
--skeleton-shine-amplitude: 200%;
}
让 JS 也能通过 element.style.setProperty('--skeleton-shine-speed', '2.2s') 实时干预。
如何复用同一套 keyframes 实现不同节奏的列表加载
列表项同步闪烁是骨架屏最假的细节。真实加载是逐行浮现，必须错开延迟——但不能手写 animation-delay: 0.1s、0.2s……
- 用
@for循环生成类名：.skeleton-item:nth-child(1) { animation-delay: 0.1s; }直到n - 更推荐用属性选择器 + 计算：
[data-skeleton-index="2"] { animation-delay: calc(var(--skeleton-base-delay, 0.1s) * 2); } - 必须加
animation-fill-mode: backwards，否则第一帧空白期太长，用户会误以为卡住 - 移动端建议把
--skeleton-base-delay设为0.05s，避免长列表延迟累积超过 1s，破坏“正在加载”的心理预期
容易被忽略的性能断点：background-size 和渐变色 stops
骨架屏动画卡顿，90% 出在 background-size 设置过大或渐变色 stop 过密：
-
background-size: 400% 100%是安全上限；超过 500%，iOS Safari 会触发 CPU 渲染，帧率骤降 - 渐变色 stops 必须控制在 3 段以内（如
transparent 0%, #f0f0f0 25%, transparent 50%），Chrome 对 >5 段的 linear-gradient 解析开销明显上升 - 如果项目需兼容 IE11，不要用
background-image方案，改用::after伪元素 +opacity动画，并通过@supports not (background-image: linear-gradient())隔离
变量和关键帧本身不重，重的是你怎么用它们组织渲染路径——扫光动画本质是 background-position 位移，不是 opacity 切换，这点一旦搞反，优化就全白做了。
