SCSS可通过编译期循环生成多套独立命名的关键帧规则（如skeleton-shine-slow/medium/fast）实现真正可控、可复用的骨架屏动画，避免CSS变量在@keyframes中无法动态更新的根本限制。
CSS 变量不能直接驱动 @keyframes 中的动画节奏，但 SCSS 可以在编译期生成多套不同参数的关键帧规则——这是真正可控、可复用、且兼容性拉满的方案。
SCSS 循环生成不同 speed 的 @keyframes 规则
核心不是“动态改动画”，而是让 SCSS 在构建时就产出 skeleton-shine-slow、skeleton-shine-medium、skeleton-shine-fast 等多个独立动画名。浏览器只认最终 CSS，不关心你是不是用循环写的。
实操建议：
- 用
@for或@each遍历预设的速度档位（如(slow: 2s, medium: 1.5s, fast: 1s)），为每个档位生成专属@keyframes - 动画名必须唯一，避免覆盖；推荐格式：
skeleton-shine-#{$name} - 关键帧内不要写
calc()或变量引用，全部展开为静态值（如0% { background-position: -200% 50%; }） - 生成的动画规则体积可控——10 个档位也就增加 ~1KB CSS，远小于 JS 注入或运行时重写 style 标签的成本
如何让列表项错开闪烁（非同步动画）
真实加载是逐行浮现，骨架屏若全齐刷刷闪，反而暴露“假加载”。SCSS 可在生成类名时一并注入 animation-delay。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 配合
@for $i from 1 through 10，给每个.skeleton-item:nth-child(#{$i})设置animation-delay: #{$i * 0.08}s - 延迟值别用整数秒（如
0.1s、0.2s），小步长（0.06s–0.12s）更自然，也避免视觉卡顿 - 慎用
animation-direction: alternate：它会让光效反向跑，和相邻项节奏冲突，容易看出“接缝” - 若用 Vue/React 动态渲染列表，SCSS 生成的类名仍有效——只要元素挂载后有对应 class，CSS 就生效
为什么不用 @property 或纯 CSS 变量控制闪烁节奏
因为它们不解决根本问题：浏览器解析 @keyframes 时，所有 var(--x) 已被固化为初始值，后续变量变更不会触发重计算或重播动画。
典型失效场景：
-
@keyframes shine { 0% { opacity: var(--opacity-start); } 100% { opacity: var(--opacity-end); } }→ 动画永远卡在编译那一刻的值 -
animation-duration: calc(var(--speed) * 1s)→ 大部分浏览器无视，Safari 16.4+ 才支持calc()在@keyframes内部 - 试图用 JS 改
style.setProperty('--speed', '0.5')→ 动画不会变慢，只会继续按旧节奏跑
SCSS 方案绕开了这个限制：它把“变化”提前到构建阶段，输出的是干净、确定、无 runtime 依赖的 CSS。
SCSS 生成的骨架动画如何与主题色联动
可以，但要分清边界：动画节奏交给 SCSS 编译生成，而颜色等静态样式由 CSS 变量承接，两者正交协作。
实操建议：
- 定义主题变量：
$theme-shine-light: #e0e0e0;、$theme-shine-dark: #333;，在 SCSS 中直接用于linear-gradient声明 - 保留一个根级 CSS 变量如
--skeleton-bg，供深色模式切换时 JS 修改，影响的是background-color等静态层，不影响已生成的动画规则 - 不要在 SCSS 循环里拼接 CSS 变量名（如
var(--#{$name}-speed)），这会导致编译失败——SCSS 不解析运行时变量
真正难的不是写循环，而是想清楚哪些该在编译期定死（节奏、延迟、关键帧位置），哪些该留到运行时换（颜色、启停开关）。混用这两层，骨架屏才既灵活又可靠。
