先说句实在话：CSS加载光效这东西，我做前端这几年几乎每个项目都会碰到。小到按钮 loading，大到后台管理系统整页骨架屏，总得有点“光”在动，用户才觉得页面没死。这个标题看着简单，背后其实堆了不少细节——渐变方向、动画曲线、合成器属性、无障碍降级，每一步都有讲究。这篇就把我从实操里摸出来的东西整理一遍，从原理讲到代码，再讲到我踩过的坑，希望能帮你少走点弯路。1. 加载光效到底在解决什么问题1.1 用户体验层面的真实诉求加载光效本质上是“状态反馈”的视觉化表达。用户点了按钮、刷新了页面，网络请求还没回来，界面必须给出一个“我正在努力”的信号，否则用户会把白屏误判成卡死，直接关掉页面。从数据来看，超过 3 秒没反馈的页面，跳出率会明显上升，这已经是行业共识了。光效和传统 loading 图标最大的区别在于：它不只是告诉用户“在加载”，还能通过光的流动方向、速度、范围，暗示加载的“进度感”。比如一条光带从左到右扫过骨架屏，用户会下意识觉得数据正在逐步就绪；一个旋转的光晕，用户会知道系统还在处理中。这种微妙的心理暗示，是普通转圈图标做不到的。所以加载光效不是一个纯装饰功能，它是体验设计里最便宜、见效最快的“止痛药”。不需要后端配合，不需要改架构，纯前端加几行 CSS 就能让用户对页面速度的感知提升一大截。1.2 为什么偏偏用 CSS 来实现这个问题我经常被问到。确实，JS 也能做光效，用 requestAnimationFrame 控制一个元素的位置或者颜色，理论上更灵活。但实际项目里我基本都用 CSS，原因很现实：代码量少。一个 shimmer 效果，CSS 二十行以内搞定，JS 方案至少多写三倍代码，还要处理生命周期、取消动画、内存释放。性能更好。CSS 动画只要用对属性（transform、opacity、background-position），就能跑在浏览器的合成器线程上，不会阻塞主线程的 JS 任务。页面加载阶段主线程本来就很忙，要解析 HTML、执行脚本、计算样式，再去占用主线程做动画，纯属给自己添堵。心智负担低。CSS 动画的语法天然贴近“我要什么效果”，@keyframes 里写起始和结束状态就行，中间过程浏览器帮你算。JS 方案你得自己维护每一帧的状态，边界情况一多就崩。当然，CSS 不是万能的。遇到复杂的路径动画、需要响应用户交互的光效逻辑、或者要同步多个元素状态的时候，我会考虑 GSAP 或者 Framer Motion。但 90% 的加载光效场景，CSS 是性价比最高的选择。1.3 光效的三种主流形态我把日常开发里碰到的加载光效归纳成三大类，覆盖了绝大多数业务场景：骨架屏扫光。页面加载时先用灰色占位块勾勒出内容布局，然后一束光反复扫过这些占位块。常见于内容型产品、后台列表页、详情页。这类光效的核心是渐变背景的位移动画。按钮流光。按钮处在 loading 状态时，表面有一条斜向的光带循环划过，或者按钮整体有呼吸般的光晕变化。常见于提交表单、保存设置、支付确认场景。核心是伪元素的平移配合裁剪。独立加载图标。页面局部或全局的独立加载指示器，常见的是旋转的圆环、跳动的小球、扩散的波纹，光效叠加在形状之上产生发光感。核心是旋转动画加渐变和阴影的组合。三种形态没有绝对的边界，很多页面会混合使用。比如列表页第一屏用骨架屏扫光，底部“加载更多”按钮用按钮流光，两者配合，整体体验非常统一。2. 核心技术原理解读2.1 渐变是光效的灵魂几乎所有加载光效都离不开渐变。JS 工程师看到的是“一束光在动”，但我眼里就是一个线性渐变在改变位置。光的本质是高亮区域，而高亮区域用渐变模拟最自然——它不是一条生硬的边缘线，而是一个从透明到亮色再到透明的平滑过渡。线性渐变的写法是 linear-gradient(角度, 颜色节点1, 颜色节点2, ...)。光效里最经典的组合是三个颜色节点：透明-亮色-透明。中间的颜色节点决定了光的“亮度”和“宽度”，两端的透明决定了光的“边缘柔和度”。骨架屏的常规配色是基础灰 #e8e8e8 作为底，渐变亮色用 #f5f5f5 到 #e8e8e8 的过渡。如果想更闪一点，亮色可以提高到白色或者带一点品牌色的高亮，比如蓝色调的 rgba(59, 130, 246, 0.3)，在品牌色系统里很出效果。有一个控制光的“聚拢感”的小技巧：把渐变的角度和颜色节点的位置调好，能让光看起来像从某个光源照过来。比如 120 度角的光带，配合较窄的中间亮色区域（控制在渐变总长度的 30% 左右），就比宽泛的亮色区域更有“光”的质感，而不是一大片灰白。2.2 background-position 与 background-size 的配合逻辑骨架屏扫光最容易写错的就是这两个属性的配合。很多人直接写一个 background 动画，发现光不动，或者光的位置不对，问题基本都出在 background-size 上。默认情况下 background-size 是 auto，也就是渐变默认填满整个元素。填满了，你再怎么移动 background-position，背景都已经占满整个区域了，光自然“动不起来”。所以第一步必须把 background-size 放大，至少要 200% 宽度，留出移动的空间。我常用的是：背景宽度设为 200% 或 300%，然后通过 animation 控制 background-position 从一端移到另一端。当 background-size 为 200% 时，background-position 的移动范围正好是一个完整周期，光从左边扫到右边，再循环回来。这里有一个关键认知：background-position 百分比的含义和像素不同。像素是“背景图左上角距离容器左上角的偏移”，而百分比计算的是“背景图尺寸减去容器尺寸后的偏移比例”。所以 200% 的 background-size，加上 background-position 从 200% 到 -200% 的动画，就能让光无限循环扫过。这个逻辑不搞清楚，写出来的代码只能靠试，试出来了也不知道为什么能跑。2.3 伪元素与 transform 构建扫光路径按钮流光类效果，我习惯用 ::before 或 ::after 配合 overflow: hidden 来做。简单说：在按钮内部放一个宽高比按钮大的伪元素，给它一个渐变背景，然后让它在按钮内部移动。按钮本身设置 overflow: hidden，伪元素移出按钮的部分就被裁掉，视觉上就像一束光扫过按钮表面。为什么用伪元素做扫光而不是用 background-position？因为按钮流光常常配合圆角、边框、阴影，伪元素方案更灵活。你可以给伪元素设不同的 transform 变换——旋转、斜切、位移，光带的形态千变万化，不受 background 属性局限。具体做法：伪元素初始位置在左侧（比如 left: -100%），transform: skewX(-20deg) 让它产生一个斜向的倾角，也就是光带看起来和水平方向有一个夹角。动画让它从左侧平移到右侧，因为加了斜切，视觉上就像一条斜光带掠过按钮。这条光带在移动时，末端会从按钮右侧滑入再滑出。想控制光带长短，调整伪元素的 width 就行；想控制光的覆盖范围，调整渐变里透明区域的比例。我把这套玩法总结成一个公式：位置（left/top）+ 形变（skew/rotate）+ 裁剪（overflow hidden） = 任意方向的扫光。2.4 合成器线程与动画性能的关系这一节是进阶内容，但我觉得是必答题，因为加载光效常见的使用场景就是页面加载阶段，这时候性能问题会被放大。浏览器的渲染流程大致是：JS 执行-样式计算-布局-绘制-合成。其中布局和绘制是最耗时的两步。如果动画触发了布局（比如改了 width、top、left），每一帧都要重新走一遍完整流程，叫做“重排”，性能开销巨大。如果只触发绘制（改了 background-color、box-shadow），叫做“重绘”，好转一些，但仍然占用主线程。真正省力的是只触发合成。合成是浏览器把页面拆成多个图层，只更新和动画相关的图层。能触发合成的属性主要是 transform 和 opacity。这意味着，如果光效动画只改 transform 和 opacity，浏览器能把它放在 GPU 上跑，完全不占用主线程。回到实操上：骨架屏扫光的 background-position 动画，实际是走绘制流程的，因为背景的变化需要重新绘制。好在背景绘制开销不大，而且现在浏览器对 background-position 动画做了一定的合成优化，实测大多数场景依然流畅。但如果你发现帧率掉了、动画卡了，优先把 background-position 动画替换成 transform 动画——用一个覆盖全元素的高亮渐变层，在元素内部移动它的 transform 属性，效果一样，性能提升明显。还有一个容易被忽略的点：动画元素如果没被提升成独立图层，浏览器可能把它和其他元素一起绘制，导致动画引起周边区域的重绘。在动画开始前加一句 will-change: transform（或者 will-change: background-position），可以提前告诉浏览器“这个元素要动，先给它独立图层”。但有得必有失，will-change 会让元素常驻内存，如果页面里有十几个动画元素，十几个独立图层会占用大量内存，甚至引发移动端崩溃。所以 will-change 只加在真正需要动画的核心元素上，用完记得在动画结束后移除。3. 实操：三种高频加载光效从零实现3.1 骨架屏扫光（shimmer 效果）骨架屏是最常见的加载光效场景。我先给一个最基础的版本，然后讲怎么调整参数。.skeleton { border-radius: 8px; background: linear-gradient( 90deg, #e8e8e8 25%, #f5f5f5 37%, #e8e8e8 63% ); background-size: 400% 100%; animation: shimmer 1.4s ease-in-out infinite; } @keyframes shimmer { 0% { background-position: 100% 0; } 100% { background-position: 0 0; } }这里 background-size 设成 400%，即背景渐变宽度是元素宽度的 4 倍。动画把 background-position 从 100%（完全靠右）移到 0%（完全靠左），结合 400% 的背景尺寸，正好产生一束光从右到左扫过占位块的效果。关键参数怎么调：亮色区域宽度。渐变中亮色节点的位置（37%）和两端的暗色节点的位置（25%、63%）越接近，亮带越窄，光越“聚拢”；反之亮带越宽，光越“柔和”。文本骨架通常用窄亮带，图片占位通常用宽亮带，因为图片区域大，窄亮带看不出来。动画时长。1.4 秒是我测下来比较舒服的节奏。短于 1 秒会显得急促，用户会觉得系统在“疯狂加载”，反而制造焦虑；超过 2 秒会显得拖沓，光移动得慢，用户会感觉加载过程很漫长。1.2 到 1.6 秒是一个合理区间。动画曲线。ease-in-out 是我首选的缓动曲线，因为光在两端减速、中间匀加速，更接近真实光照的物理感受。linear 会让光匀速移动，虽然简单，但视觉上有一点“机械感”。我用 ease-in-out 之后，同事普遍反馈“光舒服了很多”。3.2 按钮流光（sweep 效果）按钮提交后进入 loading 状态，一个斜向光带扫过，是强化“正在处理”感知的好手段。核心实现如下：.btn-loading { position: relative; overflow: hidden; } .btn-loading::after { content: ""; position: absolute; top: 0; left: -150%; width: 60%; height: 100%; background: linear-gradient( 120deg, transparent 20%, rgba(255, 255, 255, 0.5) 50%, transparent 80% ); transform: skewX(-20deg); animation: sweep 2.5s ease-in-out infinite; } @keyframes sweep { 0% { left: -150%; } 100% { left: 250%; } }为什么用 left 而不是 transform 的 translateX？我之前提过性能上 transform 更好，这里其实可以改成 transform 方案：.btn-loading::after { transform: translateX(-150%) skewX(-20deg); animation: sweep 2.5s ease-in-out infinite; } @keyframes sweep { 0% { transform: translateX(-150%) skewX(-20deg); } 100% { transform: translateX(350%) skewX(-20deg); } }注意第二个方案的技巧：skewX(-20deg) 在 translateX 的基础上叠加，动画里必须同时保留 skew 变换，否则到终点时光带的角度会突然变直。我踩过这个坑——第一版写动画时只写了 translateX，结果扫到一半光突然“立正”，非常尴尬。还有一个细节：按钮圆角较大时，光带扫到边缘会出现“断头”的视觉瑕疵，因为伪元素被 overflow: hidden 裁剪时，沿斜边的抗锯齿处理在圆角处会有一丝生硬。轻微缓解的办法是加一点内阴影保留按钮自身的质感：.btn-loading { box-shadow: inset 0 1px 3px rgba(0, 0, 0, 0.1); }这样光带滑过时，按钮边缘有自然的立体过渡，瑕疵几乎不可见。3.3 加载转圈光晕独立加载图标的场景，我想讲一个带光晕效果的旋转圆环。它的核心不仅仅是旋转，还有渐变和滤镜产生的光感。.spinner { width: 48px; height: 48px; border-radius: 50%; background: conic-gradient( from 0deg, transparent 10%, rgba(59, 130, 246, 0.8) 60%, transparent 100% ); -webkit-mask: radial-gradient(farthest-side, transparent calc(100% - 6px), #000 100%); mask: radial-gradient(farthest-side, transparent calc(100% - 6px), #000 100%); animation: spin 0.9s linear infinite; } @keyframes spin { to { transform: rotate(360deg); } }要点拆解：conic-gradient 是一种锥形渐变，颜色围绕圆心呈环形分布。这里从 0 度开始，10% 是透明，60% 到达亮色峰值，100% 恢复透明。这样形成的不是均匀的圆环，而是有一端亮、一端暗的“角动量”光带，旋转时视觉上有一个明显的高光点绕着圆跑。mask 的作用是让渐变圆环变成一个只有外圈可见的圆环，中间和边缘都被透明遮罩裁掉，保留 6px 宽的光圈。很多人不理解 mask 的写法，简单说：radial-gradient 从圆心到边缘，近圆心是 transparent，远边缘是黑色（不透明），叠加后就是一个“外边缘不透明、往里渐隐”的遮罩，配合最外圈的圆环形状，就得到一个干干净净的圆弧。这个旋转动画用了 transform: rotate，纯合成器属性的动画，性能非常好。0.9 秒是一圈，视觉上比较紧凑，适合页面局部加载；全局加载可以用 1.2 秒更从容的节奏。如果想更强调整体光晕，可以给 spinner 加一层模糊的底：.spinner { filter: drop-shadow(0 0 4px rgba(59, 130, 246, 0.5)); }drop-shadow 会顺着元素的 alpha 轮廓生成光晕，锥形渐变的光圈得到一种“发光”的效果。注意这里用 drop-shadow 而不是 box-shadow，因为 box-shadow 只能给矩形外框投影，碰到这种圆环形状，drop-shadow 才沿元素真实轮廓走。4. 进阶：让光效更有质感的细节打磨4.1 混合模式让光真正“融入”底色基础的光效只是把亮色叠在灰色上，看起来像“贴了一层光”。如果想更高级、更有材质感，混合模式是必须的。我常用的一个是 mix-blend-mode: soft-light，它让光的亮部提亮底层、暗部略微压暗，整体看起来不那么生硬，像是“光的渗透”而非“贴纸”。骨架屏用 soft-light 之后，扫光区域不是单纯的白色，而是让下层骨架的灰度显示出一种更柔和的明暗起伏，很接近真实布料或纸张在光下的质感。另一个是 overlay（叠加）模式，它更适合彩色内容上叠光效。比如卡片封面图加载时，把扫光层设为 overlay 模式，光扫过的地方颜色更浓郁、更亮，对比度更强，视觉上非常华丽。但 overlay 在白色底上会变成灰蒙蒙的一片，所以要谨慎选择使用场景。实际项目中我有一条经验：如果骨架屏底色低于 220 灰度（偏深的灰），直接用普通叠加加半透明白色就行，不需要混合模式效果也够好；如果底色高于 220（非常浅的灰），soft-light 和 overlay 都能明显改观，但要把高亮渐变节点的透明度调到 0.3 以下，否则会过曝，看起来像一块光斑，闪得用户眼睛疼。4.2 多层渐变叠加做“复合光”单层渐变只有一个高亮区，看久了稍显单调。我在一些重点页面（比如导流页、首屏品牌区）会做多层渐变复合光效。原理很简单：把同一元素设多个背景层，每层的渐变角度、运动节奏不同，视觉上就形成两束光交错运动的效果。.hero-skeleton { background: linear-gradient(120deg, transparent 20%, rgba(255, 255, 255, 0.4) 40%, transparent 60%), linear-gradient(240deg, transparent 20%, rgba(255, 255, 255, 0.2) 50%, transparent 80%), #e8e8e8; background-size: 200% 100%, 300% 100%, auto; background-position: 100% 0, 0% 0, 0 0; background-repeat: no-repeat; animation: dual-shimmer 2.4s ease-in-out infinite; } @keyframes dual-shimmer { 0% { background-position: 100% 0, 0% 0, 0 0; } 50% { background-position: 0% 0, 100% 0, 0 0; } 100% { background-position: -100% 0, 200% 0, 0 0; } }两层渐变各自带着不同的动画位移和透明度，视觉上是一明一暗两束光交叉扫过，质感立刻提升一个档次。但多层背景加多层动画，代码可读性和维护成本都在上升。我一般只在重点页面用，或者做成一个独立的 .hero-skeleton 类，避免写死在业务组件里。另一个注意点是 background 的简写顺序：第一个值对应 background-size 的第一个值，第二个对应第二个，顺序不能乱，否则视觉效果会完全错乱，排查起来很费劲。我建议用完整属性写法（background-image、background-size、background-position 分三行写），比 background 简写可读性强很多。4.3 无障碍适配关键尺寸说到加载光效，很多开发者会忽略一个群体：对动态内容敏感的用户。有些用户面临前庭障碍，长时间闪烁、扫动的大范围动效会引发头晕甚至恶心。这不是个例，是无障碍规范里明确要求的场景。标准做法是支持 prefers-reduced-motion：@media (prefers-reduced-motion: reduce) { .skeleton, .btn-loading::after, .spinner { animation: none !important; } }关掉动画之后，界面必须还能正确表达“加载状态”。骨架屏应该保留静态的灰色占位块，但去掉扫光；按钮保留 loading 文案和禁用态；独立加载图标可以保留一个静态圆环。也就是说：状态反馈不能被移除，只是去除“运动”这个维度。我在项目里执行的是“动效分级”策略：级别一：装饰型光效，比如按钮扫光，可完全移除级别二：状态指示型光效，比如骨架屏，保留静态占位但去掉动画级别三：操作反馈型光效，比如加载进度条，保留文字和数字展示，同时关掉动画这样做既符合无障碍要求，也不会因为取消动画而丢失必要的信息。很多团队只做了骨架屏的降级，按钮和加载图标的动画忘关，这是最常见的疏漏。另外一个容易踩的点是：页面加载阶段 JS 还没完全就绪，prefers-reduced-motion 的媒体查询是用 CSS 写的，所以能在 CSS 层面生效。但有些团队把降级逻辑写在 JS 里，JS 没加载完降级就不会触发，等 JS 跑起来用户该被晃的已经晃完了。所以这个降级一定要写在 CSS 里，不要依赖 JS。我在实际项目里用媒体查询写在全局样式文件顶部，统一管理所有和动效相关的降级规则，效果干净利落。5. 性能优化与兼容性踩坑实录5.1 帧率与动画流畅度实测观察加载光效出现在页面加载阶段，这个阶段渲染压力是最大的。我实测过不少页面，发现卡顿的元凶往往不是光效本身，而是页面里同时发生的大面积重排。举个实际案例：一个后台列表页，第一版方案里每个列表项用 background-position 做扫光，同时列表项的容错机制里包含了 min-height 的调整逻辑。列表项高度在加载过程中变了，触发整列重排，再叠加 20 个骨架项的 background 动画，帧率直接掉到 15 帧左右，肉眼可见的卡顿。排查思路分三步：第一步，排查有没有动画元素之外的布局抖动。用浏览器开发者工具的性能面板录制一小段加载过程，看 Layout 事件是不是反复触发。如果 Layout 事件密集出现，说明页面里有元素在加载过程中改变了尺寸或者布局位置，这些问题优先解决，动画反而是次要矛盾。第二步，检查动画是否同时触发多个高开销属性。background-position、box-shadow、filter 都是绘制阶段高开销的属性，如果多个动画元素同时更新这些属性，主线程压力陡增。一个优化思路是给每个动画元素加 will-change: transform，强制提升为合成层，动画完全走合成器线程。第三步，限制动画元素数量。页面同时出现 50 个以上的骨架项扫光时，即使都是 transform 动画，合成层数量过多也会让渲染进程吃不消。我在长列表场景会控制骨架屏数量，只渲染首屏可见的十几个，或者用一个覆盖整个列表的伪元素模拟“整屏扫光”，而不是逐项各自扫。整屏扫光性能比逐项扫光高出一个数量级。5.2 兼容性下探与降级方案CSS 光效涉及的特性和兼容性，我做了一张速查表供参考：特性浏览器支持情况风险点linear-gradient全量支持无conic-gradient现代浏览器支持老版本 Safari 不支持，需要 fallbackmask / -webkit-mask现代浏览器支持，Safari 需带 -webkit- 前缀不带前缀的写法在 Safari 上会失效mix-blend-mode现代浏览器支持部分低版本浏览器不支持，混合模式失效后可能显示为普通叠加prefers-reduced-motion现代浏览器支持不支持的浏览器等同默认状态transform 动画全量支持无background-position 动画全量支持性能和合成优化程度在不同浏览器差异大遇到兼容性问题，我的原则是“优雅降级”——新特性增强体验，老特性保底可用。conic-gradient 的例子很典型。老 Safari 不认锥形渐变，加载图标会退化成一个空白圆环。我的处理方式是先写一层基础边框圆环（普通 border 画的圆），再叠加 conic-gradient 的光效层。浏览器支持 conic-gradient 时显示光效，不支持时就显示静态边框，加载状态依然明确。mask 同理，加前缀版本就够用，Safari 全部版本都支持 -webkit-mask，只需要写两份兼容代码。mix-blend-mode 的不兼容后果比较隐蔽：光效层不参与混合，直接平铺在元素上。如果光效层透明度高、对比度强，视觉上变成一块突兀的白色光斑，比没有光效还难看。我的做法是在混合模式之外把光效层的透明度控制得低一些（0.5 以下），即使混合失败，也只是普通的半透明覆盖，不至于刺眼。5.3 常见问题排查速查表光效写多了，遇到的问题基本都能归类。我做了一份排查速查表：症状可能原因解决办法光不动background-size 没放大到超过元素尺寸background-size 设为 200% 以上光扫过一次后消失animation-iteration-count 默认为 1设置 infinite光来回扫而不是单向循环background-position 在 0 和 100% 之间往复把范围改为负值和超过 100% 的值光快到看不清动画时长太短延长 duration 至 1.2 秒以上光模糊发虚亮色节点透明度太低或模糊太重提高亮色节点透明度，移除多余的 blur按钮光扫到圆角断头overflow: hidden 在圆角处的抗锯齿问题减少光带宽度，增加按钮内阴影多个动画元素卡顿缺少合成层提升加 will-change: transform，限制动画元素数量Safari 显示空白圆环mask 前缀缺失或 conic-gradient 不受支持添加 -webkit-mask，提供基础边框 fallback关掉动画后状态无法辨识降级策略缺失用静态占位或文字反馈代替动画排查速度快的核心思路是：先确认动画属性本身有没有生效（打开开发者工具，看看 computed style 里 animation 是否在跑），再确认是不是被其他样式干扰（比如 display: none 或者父级 overflow 隐藏），然后再怀疑性能问题。大部分光效问题都是属性作用域和覆盖顺序造成的，而不是底层逻辑错误。说一点我个人的体会：CSS 加载光效是我见过“门槛最低、天花板最高”的前端技巧之一。入门只需要一个 linear-gradient 加一个 @keyframes，任何人都能半小时内做出一个小 demo。但真正做好——把光的节奏调到让用户舒服、把性能压到不掉帧、把无障碍考虑周全、把兼容性差异抹平——这些细节要打磨很久。如果你是从零开始，我的建议是从骨架屏扫光入手，把一个效果吃透，再把按钮流光加进去，最后再碰多层渐变和混合模式。光效这东西，永远是基础功先稳，再谈惊艳。上面这套东西我写出来，希望能帮你避开我踩过的坑。后续你在项目里遇到具体的光效场景，欢迎顺着这个思路往上加自己的变体，玩出更多花样。
先说句实在话：CSS加载光效这东西，我做前端这几年几乎每个项目都会碰到。小到按钮 loading，大到后台管理系统整页骨架屏，总得有点“光”在动，用户才觉得页面没死。这个标题看着简单，背后其实堆了不少细节——渐变方向、动画曲线、合成器属性、无障碍降级，每一步都有讲究。这篇就把我从实操里摸出来的东西整理一遍，从原理讲到代码，再讲到我踩过的坑，希望能帮你少走点弯路。1. 加载光效到底在解决什么问题1.1 用户体验层面的真实诉求加载光效本质上是“状态反馈”的视觉化表达。用户点了按钮、刷新了页面，网络请求还没回来，界面必须给出一个“我正在努力”的信号，否则用户会把白屏误判成卡死，直接关掉页面。从数据来看，超过 3 秒没反馈的页面，跳出率会明显上升，这已经是行业共识了。光效和传统 loading 图标最大的区别在于：它不只是告诉用户“在加载”，还能通过光的流动方向、速度、范围，暗示加载的“进度感”。比如一条光带从左到右扫过骨架屏，用户会下意识觉得数据正在逐步就绪；一个旋转的光晕，用户会知道系统还在处理中。这种微妙的心理暗示，是普通转圈图标做不到的。所以加载光效不是一个纯装饰功能，它是体验设计里最便宜、见效最快的“止痛药”。不需要后端配合，不需要改架构，纯前端加几行 CSS 就能让用户对页面速度的感知提升一大截。1.2 为什么偏偏用 CSS 来实现这个问题我经常被问到。确实，JS 也能做光效，用 requestAnimationFrame 控制一个元素的位置或者颜色，理论上更灵活。但实际项目里我基本都用 CSS，原因很现实：代码量少。一个 shimmer 效果，CSS 二十行以内搞定，JS 方案至少多写三倍代码，还要处理生命周期、取消动画、内存释放。性能更好。CSS 动画只要用对属性（transform、opacity、background-position），就能跑在浏览器的合成器线程上，不会阻塞主线程的 JS 任务。页面加载阶段主线程本来就很忙，要解析 HTML、执行脚本、计算样式，再去占用主线程做动画，纯属给自己添堵。心智负担低。CSS 动画的语法天然贴近“我要什么效果”，@keyframes 里写起始和结束状态就行，中间过程浏览器帮你算。JS 方案你得自己维护每一帧的状态，边界情况一多就崩。当然，CSS 不是万能的。遇到复杂的路径动画、需要响应用户交互的光效逻辑、或者要同步多个元素状态的时候，我会考虑 GSAP 或者 Framer Motion。但 90% 的加载光效场景，CSS 是性价比最高的选择。1.3 光效的三种主流形态我把日常开发里碰到的加载光效归纳成三大类，覆盖了绝大多数业务场景：骨架屏扫光。页面加载时先用灰色占位块勾勒出内容布局，然后一束光反复扫过这些占位块。常见于内容型产品、后台列表页、详情页。这类光效的核心是渐变背景的位移动画。按钮流光。按钮处在 loading 状态时，表面有一条斜向的光带循环划过，或者按钮整体有呼吸般的光晕变化。常见于提交表单、保存设置、支付确认场景。核心是伪元素的平移配合裁剪。独立加载图标。页面局部或全局的独立加载指示器，常见的是旋转的圆环、跳动的小球、扩散的波纹，光效叠加在形状之上产生发光感。核心是旋转动画加渐变和阴影的组合。三种形态没有绝对的边界，很多页面会混合使用。比如列表页第一屏用骨架屏扫光，底部“加载更多”按钮用按钮流光，两者配合，整体体验非常统一。2. 核心技术原理解读2.1 渐变是光效的灵魂几乎所有加载光效都离不开渐变。JS 工程师看到的是“一束光在动”，但我眼里就是一个线性渐变在改变位置。光的本质是高亮区域，而高亮区域用渐变模拟最自然——它不是一条生硬的边缘线，而是一个从透明到亮色再到透明的平滑过渡。线性渐变的写法是 linear-gradient(角度, 颜色节点1, 颜色节点2, ...)。光效里最经典的组合是三个颜色节点：透明-亮色-透明。中间的颜色节点决定了光的“亮度”和“宽度”，两端的透明决定了光的“边缘柔和度”。骨架屏的常规配色是基础灰 #e8e8e8 作为底，渐变亮色用 #f5f5f5 到 #e8e8e8 的过渡。如果想更闪一点，亮色可以提高到白色或者带一点品牌色的高亮，比如蓝色调的 rgba(59, 130, 246, 0.3)，在品牌色系统里很出效果。有一个控制光的“聚拢感”的小技巧：把渐变的角度和颜色节点的位置调好，能让光看起来像从某个光源照过来。比如 120 度角的光带，配合较窄的中间亮色区域（控制在渐变总长度的 30% 左右），就比宽泛的亮色区域更有“光”的质感，而不是一大片灰白。2.2 background-position 与 background-size 的配合逻辑骨架屏扫光最容易写错的就是这两个属性的配合。很多人直接写一个 background 动画，发现光不动，或者光的位置不对，问题基本都出在 background-size 上。默认情况下 background-size 是 auto，也就是渐变默认填满整个元素。填满了，你再怎么移动 background-position，背景都已经占满整个区域了，光自然“动不起来”。所以第一步必须把 background-size 放大，至少要 200% 宽度，留出移动的空间。我常用的是：背景宽度设为 200% 或 300%，然后通过 animation 控制 background-position 从一端移到另一端。当 background-size 为 200% 时，background-position 的移动范围正好是一个完整周期，光从左边扫到右边，再循环回来。这里有一个关键认知：background-position 百分比的含义和像素不同。像素是“背景图左上角距离容器左上角的偏移”，而百分比计算的是“背景图尺寸减去容器尺寸后的偏移比例”。所以 200% 的 background-size，加上 background-position 从 200% 到 -200% 的动画，就能让光无限循环扫过。这个逻辑不搞清楚，写出来的代码只能靠试，试出来了也不知道为什么能跑。2.3 伪元素与 transform 构建扫光路径按钮流光类效果，我习惯用 ::before 或 ::after 配合 overflow: hidden 来做。简单说：在按钮内部放一个宽高比按钮大的伪元素，给它一个渐变背景，然后让它在按钮内部移动。按钮本身设置 overflow: hidden，伪元素移出按钮的部分就被裁掉，视觉上就像一束光扫过按钮表面。为什么用伪元素做扫光而不是用 background-position？因为按钮流光常常配合圆角、边框、阴影，伪元素方案更灵活。你可以给伪元素设不同的 transform 变换——旋转、斜切、位移，光带的形态千变万化，不受 background 属性局限。具体做法：伪元素初始位置在左侧（比如 left: -100%），transform: skewX(-20deg) 让它产生一个斜向的倾角，也就是光带看起来和水平方向有一个夹角。动画让它从左侧平移到右侧，因为加了斜切，视觉上就像一条斜光带掠过按钮。这条光带在移动时，末端会从按钮右侧滑入再滑出。想控制光带长短，调整伪元素的 width 就行；想控制光的覆盖范围，调整渐变里透明区域的比例。我把这套玩法总结成一个公式：位置（left/top）+ 形变（skew/rotate）+ 裁剪（overflow hidden） = 任意方向的扫光。2.4 合成器线程与动画性能的关系这一节是进阶内容，但我觉得是必答题，因为加载光效常见的使用场景就是页面加载阶段，这时候性能问题会被放大。浏览器的渲染流程大致是：JS 执行-样式计算-布局-绘制-合成。其中布局和绘制是最耗时的两步。如果动画触发了布局（比如改了 width、top、left），每一帧都要重新走一遍完整流程，叫做“重排”，性能开销巨大。如果只触发绘制（改了 background-color、box-shadow），叫做“重绘”，好转一些，但仍然占用主线程。真正省力的是只触发合成。合成是浏览器把页面拆成多个图层，只更新和动画相关的图层。能触发合成的属性主要是 transform 和 opacity。这意味着，如果光效动画只改 transform 和 opacity，浏览器能把它放在 GPU 上跑，完全不占用主线程。回到实操上：骨架屏扫光的 background-position 动画，实际是走绘制流程的，因为背景的变化需要重新绘制。好在背景绘制开销不大，而且现在浏览器对 background-position 动画做了一定的合成优化，实测大多数场景依然流畅。但如果你发现帧率掉了、动画卡了，优先把 background-position 动画替换成 transform 动画——用一个覆盖全元素的高亮渐变层，在元素内部移动它的 transform 属性，效果一样，性能提升明显。还有一个容易被忽略的点：动画元素如果没被提升成独立图层，浏览器可能把它和其他元素一起绘制，导致动画引起周边区域的重绘。在动画开始前加一句 will-change: transform（或者 will-change: background-position），可以提前告诉浏览器“这个元素要动，先给它独立图层”。但有得必有失，will-change 会让元素常驻内存，如果页面里有十几个动画元素，十几个独立图层会占用大量内存，甚至引发移动端崩溃。所以 will-change 只加在真正需要动画的核心元素上，用完记得在动画结束后移除。3. 实操：三种高频加载光效从零实现3.1 骨架屏扫光（shimmer 效果）骨架屏是最常见的加载光效场景。我先给一个最基础的版本，然后讲怎么调整参数。.skeleton { border-radius: 8px; background: linear-gradient( 90deg, #e8e8e8 25%, #f5f5f5 37%, #e8e8e8 63% ); background-size: 400% 100%; animation: shimmer 1.4s ease-in-out infinite; } @keyframes shimmer { 0% { background-position: 100% 0; } 100% { background-position: 0 0; } }这里 background-size 设成 400%，即背景渐变宽度是元素宽度的 4 倍。动画把 background-position 从 100%（完全靠右）移到 0%（完全靠左），结合 400% 的背景尺寸，正好产生一束光从右到左扫过占位块的效果。关键参数怎么调：亮色区域宽度。渐变中亮色节点的位置（37%）和两端的暗色节点的位置（25%、63%）越接近，亮带越窄，光越“聚拢”；反之亮带越宽，光越“柔和”。文本骨架通常用窄亮带，图片占位通常用宽亮带，因为图片区域大，窄亮带看不出来。动画时长。1.4 秒是我测下来比较舒服的节奏。短于 1 秒会显得急促，用户会觉得系统在“疯狂加载”，反而制造焦虑；超过 2 秒会显得拖沓，光移动得慢，用户会感觉加载过程很漫长。1.2 到 1.6 秒是一个合理区间。动画曲线。ease-in-out 是我首选的缓动曲线，因为光在两端减速、中间匀加速，更接近真实光照的物理感受。linear 会让光匀速移动，虽然简单，但视觉上有一点“机械感”。我用 ease-in-out 之后，同事普遍反馈“光舒服了很多”。3.2 按钮流光（sweep 效果）按钮提交后进入 loading 状态，一个斜向光带扫过，是强化“正在处理”感知的好手段。核心实现如下：.btn-loading { position: relative; overflow: hidden; } .btn-loading::after { content: ""; position: absolute; top: 0; left: -150%; width: 60%; height: 100%; background: linear-gradient( 120deg, transparent 20%, rgba(255, 255, 255, 0.5) 50%, transparent 80% ); transform: skewX(-20deg); animation: sweep 2.5s ease-in-out infinite; } @keyframes sweep { 0% { left: -150%; } 100% { left: 250%; } }为什么用 left 而不是 transform 的 translateX？我之前提过性能上 transform 更好，这里其实可以改成 transform 方案：.btn-loading::after { transform: translateX(-150%) skewX(-20deg); animation: sweep 2.5s ease-in-out infinite; } @keyframes sweep { 0% { transform: translateX(-150%) skewX(-20deg); } 100% { transform: translateX(350%) skewX(-20deg); } }注意第二个方案的技巧：skewX(-20deg) 在 translateX 的基础上叠加，动画里必须同时保留 skew 变换，否则到终点时光带的角度会突然变直。我踩过这个坑——第一版写动画时只写了 translateX，结果扫到一半光突然“立正”，非常尴尬。还有一个细节：按钮圆角较大时，光带扫到边缘会出现“断头”的视觉瑕疵，因为伪元素被 overflow: hidden 裁剪时，沿斜边的抗锯齿处理在圆角处会有一丝生硬。轻微缓解的办法是加一点内阴影保留按钮自身的质感：.btn-loading { box-shadow: inset 0 1px 3px rgba(0, 0, 0, 0.1); }这样光带滑过时，按钮边缘有自然的立体过渡，瑕疵几乎不可见。3.3 加载转圈光晕独立加载图标的场景，我想讲一个带光晕效果的旋转圆环。它的核心不仅仅是旋转，还有渐变和滤镜产生的光感。.spinner { width: 48px; height: 48px; border-radius: 50%; background: conic-gradient( from 0deg, transparent 10%, rgba(59, 130, 246, 0.8) 60%, transparent 100% ); -webkit-mask: radial-gradient(farthest-side, transparent calc(100% - 6px), #000 100%); mask: radial-gradient(farthest-side, transparent calc(100% - 6px), #000 100%); animation: spin 0.9s linear infinite; } @keyframes spin { to { transform: rotate(360deg); } }要点拆解：conic-gradient 是一种锥形渐变，颜色围绕圆心呈环形分布。这里从 0 度开始，10% 是透明，60% 到达亮色峰值，100% 恢复透明。这样形成的不是均匀的圆环，而是有一端亮、一端暗的“角动量”光带，旋转时视觉上有一个明显的高光点绕着圆跑。mask 的作用是让渐变圆环变成一个只有外圈可见的圆环，中间和边缘都被透明遮罩裁掉，保留 6px 宽的光圈。很多人不理解 mask 的写法，简单说：radial-gradient 从圆心到边缘，近圆心是 transparent，远边缘是黑色（不透明），叠加后就是一个“外边缘不透明、往里渐隐”的遮罩，配合最外圈的圆环形状，就得到一个干干净净的圆弧。这个旋转动画用了 transform: rotate，纯合成器属性的动画，性能非常好。0.9 秒是一圈，视觉上比较紧凑，适合页面局部加载；全局加载可以用 1.2 秒更从容的节奏。如果想更强调整体光晕，可以给 spinner 加一层模糊的底：.spinner { filter: drop-shadow(0 0 4px rgba(59, 130, 246, 0.5)); }drop-shadow 会顺着元素的 alpha 轮廓生成光晕，锥形渐变的光圈得到一种“发光”的效果。注意这里用 drop-shadow 而不是 box-shadow，因为 box-shadow 只能给矩形外框投影，碰到这种圆环形状，drop-shadow 才沿元素真实轮廓走。4. 进阶：让光效更有质感的细节打磨4.1 混合模式让光真正“融入”底色基础的光效只是把亮色叠在灰色上，看起来像“贴了一层光”。如果想更高级、更有材质感，混合模式是必须的。我常用的一个是 mix-blend-mode: soft-light，它让光的亮部提亮底层、暗部略微压暗，整体看起来不那么生硬，像是“光的渗透”而非“贴纸”。骨架屏用 soft-light 之后，扫光区域不是单纯的白色，而是让下层骨架的灰度显示出一种更柔和的明暗起伏，很接近真实布料或纸张在光下的质感。另一个是 overlay（叠加）模式，它更适合彩色内容上叠光效。比如卡片封面图加载时，把扫光层设为 overlay 模式，光扫过的地方颜色更浓郁、更亮，对比度更强，视觉上非常华丽。但 overlay 在白色底上会变成灰蒙蒙的一片，所以要谨慎选择使用场景。实际项目中我有一条经验：如果骨架屏底色低于 220 灰度（偏深的灰），直接用普通叠加加半透明白色就行，不需要混合模式效果也够好；如果底色高于 220（非常浅的灰），soft-light 和 overlay 都能明显改观，但要把高亮渐变节点的透明度调到 0.3 以下，否则会过曝，看起来像一块光斑，闪得用户眼睛疼。4.2 多层渐变叠加做“复合光”单层渐变只有一个高亮区，看久了稍显单调。我在一些重点页面（比如导流页、首屏品牌区）会做多层渐变复合光效。原理很简单：把同一元素设多个背景层，每层的渐变角度、运动节奏不同，视觉上就形成两束光交错运动的效果。.hero-skeleton { background: linear-gradient(120deg, transparent 20%, rgba(255, 255, 255, 0.4) 40%, transparent 60%), linear-gradient(240deg, transparent 20%, rgba(255, 255, 255, 0.2) 50%, transparent 80%), #e8e8e8; background-size: 200% 100%, 300% 100%, auto; background-position: 100% 0, 0% 0, 0 0; background-repeat: no-repeat; animation: dual-shimmer 2.4s ease-in-out infinite; } @keyframes dual-shimmer { 0% { background-position: 100% 0, 0% 0, 0 0; } 50% { background-position: 0% 0, 100% 0, 0 0; } 100% { background-position: -100% 0, 200% 0, 0 0; } }两层渐变各自带着不同的动画位移和透明度，视觉上是一明一暗两束光交叉扫过，质感立刻提升一个档次。但多层背景加多层动画，代码可读性和维护成本都在上升。我一般只在重点页面用，或者做成一个独立的 .hero-skeleton 类，避免写死在业务组件里。另一个注意点是 background 的简写顺序：第一个值对应 background-size 的第一个值，第二个对应第二个，顺序不能乱，否则视觉效果会完全错乱，排查起来很费劲。我建议用完整属性写法（background-image、background-size、background-position 分三行写），比 background 简写可读性强很多。4.3 无障碍适配关键尺寸说到加载光效，很多开发者会忽略一个群体：对动态内容敏感的用户。有些用户面临前庭障碍，长时间闪烁、扫动的大范围动效会引发头晕甚至恶心。这不是个例，是无障碍规范里明确要求的场景。标准做法是支持 prefers-reduced-motion：@media (prefers-reduced-motion: reduce) { .skeleton, .btn-loading::after, .spinner { animation: none !important; } }关掉动画之后，界面必须还能正确表达“加载状态”。骨架屏应该保留静态的灰色占位块，但去掉扫光；按钮保留 loading 文案和禁用态；独立加载图标可以保留一个静态圆环。也就是说：状态反馈不能被移除，只是去除“运动”这个维度。我在项目里执行的是“动效分级”策略：级别一：装饰型光效，比如按钮扫光，可完全移除级别二：状态指示型光效，比如骨架屏，保留静态占位但去掉动画级别三：操作反馈型光效，比如加载进度条，保留文字和数字展示，同时关掉动画这样做既符合无障碍要求，也不会因为取消动画而丢失必要的信息。很多团队只做了骨架屏的降级，按钮和加载图标的动画忘关，这是最常见的疏漏。另外一个容易踩的点是：页面加载阶段 JS 还没完全就绪，prefers-reduced-motion 的媒体查询是用 CSS 写的，所以能在 CSS 层面生效。但有些团队把降级逻辑写在 JS 里，JS 没加载完降级就不会触发，等 JS 跑起来用户该被晃的已经晃完了。所以这个降级一定要写在 CSS 里，不要依赖 JS。我在实际项目里用媒体查询写在全局样式文件顶部，统一管理所有和动效相关的降级规则，效果干净利落。5. 性能优化与兼容性踩坑实录5.1 帧率与动画流畅度实测观察加载光效出现在页面加载阶段，这个阶段渲染压力是最大的。我实测过不少页面，发现卡顿的元凶往往不是光效本身，而是页面里同时发生的大面积重排。举个实际案例：一个后台列表页，第一版方案里每个列表项用 background-position 做扫光，同时列表项的容错机制里包含了 min-height 的调整逻辑。列表项高度在加载过程中变了，触发整列重排，再叠加 20 个骨架项的 background 动画，帧率直接掉到 15 帧左右，肉眼可见的卡顿。排查思路分三步：第一步，排查有没有动画元素之外的布局抖动。用浏览器开发者工具的性能面板录制一小段加载过程，看 Layout 事件是不是反复触发。如果 Layout 事件密集出现，说明页面里有元素在加载过程中改变了尺寸或者布局位置，这些问题优先解决，动画反而是次要矛盾。第二步，检查动画是否同时触发多个高开销属性。background-position、box-shadow、filter 都是绘制阶段高开销的属性，如果多个动画元素同时更新这些属性，主线程压力陡增。一个优化思路是给每个动画元素加 will-change: transform，强制提升为合成层，动画完全走合成器线程。第三步，限制动画元素数量。页面同时出现 50 个以上的骨架项扫光时，即使都是 transform 动画，合成层数量过多也会让渲染进程吃不消。我在长列表场景会控制骨架屏数量，只渲染首屏可见的十几个，或者用一个覆盖整个列表的伪元素模拟“整屏扫光”，而不是逐项各自扫。整屏扫光性能比逐项扫光高出一个数量级。5.2 兼容性下探与降级方案CSS 光效涉及的特性和兼容性，我做了一张速查表供参考：特性浏览器支持情况风险点linear-gradient全量支持无conic-gradient现代浏览器支持老版本 Safari 不支持，需要 fallbackmask / -webkit-mask现代浏览器支持，Safari 需带 -webkit- 前缀不带前缀的写法在 Safari 上会失效mix-blend-mode现代浏览器支持部分低版本浏览器不支持，混合模式失效后可能显示为普通叠加prefers-reduced-motion现代浏览器支持不支持的浏览器等同默认状态transform 动画全量支持无background-position 动画全量支持性能和合成优化程度在不同浏览器差异大遇到兼容性问题，我的原则是“优雅降级”——新特性增强体验，老特性保底可用。conic-gradient 的例子很典型。老 Safari 不认锥形渐变，加载图标会退化成一个空白圆环。我的处理方式是先写一层基础边框圆环（普通 border 画的圆），再叠加 conic-gradient 的光效层。浏览器支持 conic-gradient 时显示光效，不支持时就显示静态边框，加载状态依然明确。mask 同理，加前缀版本就够用，Safari 全部版本都支持 -webkit-mask，只需要写两份兼容代码。mix-blend-mode 的不兼容后果比较隐蔽：光效层不参与混合，直接平铺在元素上。如果光效层透明度高、对比度强，视觉上变成一块突兀的白色光斑，比没有光效还难看。我的做法是在混合模式之外把光效层的透明度控制得低一些（0.5 以下），即使混合失败，也只是普通的半透明覆盖，不至于刺眼。5.3 常见问题排查速查表光效写多了，遇到的问题基本都能归类。我做了一份排查速查表：症状可能原因解决办法光不动background-size 没放大到超过元素尺寸background-size 设为 200% 以上光扫过一次后消失animation-iteration-count 默认为 1设置 infinite光来回扫而不是单向循环background-position 在 0 和 100% 之间往复把范围改为负值和超过 100% 的值光快到看不清动画时长太短延长 duration 至 1.2 秒以上光模糊发虚亮色节点透明度太低或模糊太重提高亮色节点透明度，移除多余的 blur按钮光扫到圆角断头overflow: hidden 在圆角处的抗锯齿问题减少光带宽度，增加按钮内阴影多个动画元素卡顿缺少合成层提升加 will-change: transform，限制动画元素数量Safari 显示空白圆环mask 前缀缺失或 conic-gradient 不受支持添加 -webkit-mask，提供基础边框 fallback关掉动画后状态无法辨识降级策略缺失用静态占位或文字反馈代替动画排查速度快的核心思路是：先确认动画属性本身有没有生效（打开开发者工具，看看 computed style 里 animation 是否在跑），再确认是不是被其他样式干扰（比如 display: none 或者父级 overflow 隐藏），然后再怀疑性能问题。大部分光效问题都是属性作用域和覆盖顺序造成的，而不是底层逻辑错误。说一点我个人的体会：CSS 加载光效是我见过“门槛最低、天花板最高”的前端技巧之一。入门只需要一个 linear-gradient 加一个 @keyframes，任何人都能半小时内做出一个小 demo。但真正做好——把光的节奏调到让用户舒服、把性能压到不掉帧、把无障碍考虑周全、把兼容性差异抹平——这些细节要打磨很久。如果你是从零开始，我的建议是从骨架屏扫光入手，把一个效果吃透，再把按钮流光加进去，最后再碰多层渐变和混合模式。光效这东西，永远是基础功先稳，再谈惊艳。上面这套东西我写出来，希望能帮你避开我踩过的坑。后续你在项目里遇到具体的光效场景，欢迎顺着这个思路往上加自己的变体，玩出更多花样。