流光动画应使用线性渐变+background-position偏移实现无缝滑动，避免transform位移；需设置错峰延迟（0.06s–0.12s步长）、禁用alternate、兼容老内核时降级为纯背景动画，并与Element Plus骨架屏配合时避免样式冲突。
用 @keyframes 定义流光动画时，别直接写 from/to 位移
骨架屏的流光效果本质是模拟光扫过灰色块的视觉动效，不是简单左右平移。直接写 @keyframes shine { from { transform: translateX(-100%); } to { transform: translateX(100%); } } 容易导致光条边缘生硬、起止突兀，尤其在宽高比不一的占位块上会“断光”。
更稳妥的做法是用线性渐变 + 背景定位偏移：
- 定义一个从左到右、透明→亮灰→透明的渐变：
background: linear-gradient(90deg, transparent, rgba(255,255,255,0.3), transparent) - 把背景尺寸设为宽度 200%、高度 100%，再用
background-position从 -100% 动到 100%，实现无缝滑入滑出 - 动画时长建议 1.6s–2.4s，太短像闪，太长像卡顿
给多个骨架项加错峰延迟，@for 循环里算 animation-delay
真实数据是逐行加载的，骨架屏若所有项同步闪烁，用户一眼就能识别出“这是假的”。必须让每个 .skeleton-item 的光效错开启动。
SCSS 的 @for 是最直接的解法：
立即学习“前端免费学习笔记（深入）”；
@for $i from 1 through 6 {
.skeleton-item:nth-child(#{$i}) {
animation-delay: #{$i * 0.08}s;
}
}注意三点：
- 延迟步长选
0.06s–0.12s，避开整数秒（如0.1s）——人眼对整齐节奏敏感，小数步长更接近自然阅读节奏 - 别用
animation-direction: alternate：它会让偶数项光效反向跑，相邻项衔接处容易出现“黑缝”，破坏流动感 - 如果骨架项数量不固定（比如由 Vue
v-for渲染），改用 CSS 自定义属性传入索引值，再用calc()算延迟，避免编译期硬编码
兼容性兜底：别依赖 transform 或 filter 做流光主逻辑
部分旧版 Android WebView 和 iOS 12 以下 Safari 对 transform + background-position 组合动画有渲染抖动或掉帧问题。若项目需兼容这类环境，优先用纯 background-position 动画，并禁用 will-change: transform。
可加一层降级判断：
.skeleton-item {
background: linear-gradient(90deg, transparent, #e0e0e0, transparent);
background-size: 200% 100%;
animation: shine 2s infinite;
}
@supports (background-position: 100% 0) {
.skeleton-item {
background-position: -100% 0;
}
}
@keyframes shine {
100% { background-position: 100% 0; }
}这样即使不支持 @supports 的老内核，也能 fallback 到基础渐变色，不至于白屏或失色。
和 Element Plus <el-skeleton></el-skeleton> 配合时，别覆盖默认 animation 类名
Element Plus 的 <el-skeleton></el-skeleton> 内部已绑定 .el-skeleton__item 并注入了默认动画类。如果你在 SCSS 里重写 .el-skeleton__item 的 animation，可能被组件内部样式优先级覆盖，或者和它的 JS 控制逻辑冲突（比如 loading 状态切换时强制重置动画）。
推荐做法是：
- 用更高权重的选择器，例如
.my-page .el-skeleton__item或加!important（仅限动画相关属性） - 把自定义流光动画命名为非通用名，比如
shine-fast，避免和框架内置的el-skeleton-fade-in-linear混淆 - 如果用了
el-skeleton的rows属性生成多行，记得在@for循环中对齐行数，别只按 DOM 结构数:nth-child—— 它实际渲染的节点顺序可能和模板不一致
流光动画最难的不是写出来，而是让每一道光都“像真的一样路过”，这取决于延迟节奏是否自然、渐变过渡是否连贯、以及和业务组件生命周期是否真正咬合。细节松动一点，用户感知上就是整个加载态失真。
