企业官网建设流程全解析

1. 从“转圈圈”说起：Loading动画到底在解决什么问题

做前端或者客户端开发的人，几乎都绕不开一个东西——加载动画。你打开一个App，白屏两秒，用户可能就退了；你点一个按钮，页面卡住没反应，用户以为死机了，又点了一次，结果提交了两遍。Loading动画看起来是个“锦上添花”的视觉装饰，实际上它承担的是系统状态反馈这个核心职责。

我做了十多年交互和前端相关的工作，见过太多项目在功能上跑得通，但一到加载环节就露怯：要么是生硬地弹一个系统默认的菊花转圈，要么是动画卡顿掉帧比不加载还难受，要么是加载完了动画没收干净，留个残影在那儿。这些问题单拎出来都不大，但叠在一起，用户对这个产品的“精致感”评价就会直线下降。

这篇文章想聊的，就是把“动画效果”和“加载动画”这两件事从实现层面彻底拆开讲清楚。动画效果是广义的，包括界面元素的位移、缩放、透明度变化、路径运动等等；加载动画是其中一个特定场景，专门用来表达“数据正在路上，请稍等”。两者在技术底层的实现逻辑是相通的，但设计思路和性能要求差别很大。

适合谁看？如果你是会写CSS和JavaScript、能看懂基本的requestAnimationFrame，但做出来的动画总觉得“差口气”的开发者，这篇内容会对你有直接帮助。如果你是对动画实现完全零基础的产品或设计同学，也能从中理解技术侧的成本边界在哪里，方便你和开发沟通时对齐预期。

下面我会从整体设计思路开始拆，然后进入核心实现细节，再给一套完整的实操流程，最后把我踩过的坑和排查经验整理出来。全程用大白话加代码示例，能直接抄作业的地方我会标清楚。

2. 动画实现的整体设计思路与方案选型

2.1 先搞清楚：你到底需要哪种动画技术路线

很多人一上来就问“动画怎么做”，这个问题太宽了。正确的问法是：这个动画的运行环境是什么，它的性能瓶颈在哪里，它需要多高的控制精度。不同的答案对应完全不同的技术选型。

我把常见的动画实现路线分成四类，你可以对照自己的场景来选：

选型的核心判断标准其实就一条：这个动画是“声明式”的还是“命令式”的。如果动画的起止状态是确定的，中间过程不需要根据运行时数据动态改变，那就用CSS，让浏览器自己去优化。如果动画的每一帧都要根据实时数据算出来，比如跟随手指的拖拽回弹、根据加载进度动态变化的波形，那就必须用JS或Canvas。

我见过一个典型的错误案例：有人用JavaScript每16毫秒去改一个元素的left值来实现一个简单的淡入效果。这就是典型的杀鸡用牛刀，而且性能还差。CSS一行transition: opacity 0.3s就能搞定的事，用JS写反而容易因为主线程阻塞而卡顿。

2.2 加载动画的特殊性：它和普通动画有什么不同

加载动画和普通交互动画最大的区别在于：它是在系统资源最紧张的时候运行的。你想想，用户为什么看到加载动画？因为数据还没到、资源还没加载完、主线程可能正忙着解析JSON或者渲染大列表。这个时候你还要跑一个动画，如果动画本身很吃资源，那就是雪上加霜。

所以加载动画的设计原则和普通动画完全相反：

• 普通动画追求表现力，可以复杂、可以炫技，因为它是用户主动触发的，系统有预期。
• 加载动画追求稳定性和低开销，它必须在系统繁忙时依然流畅，不能因为动画本身导致加载更慢。

这就解释了为什么绝大多数成熟的加载动画都是简单的旋转、脉冲、或者几个点的跳动。不是设计师偷懒，而是这些形式对CPU和GPU的占用极低，能保证在加载过程中不掉帧。

基于这个原则，加载动画的首选技术路线是CSS Animation，尤其是transform和opacity这两个属性。原因后面讲原理的时候会详细说，简单讲就是这两个属性的动画可以完全交给GPU的合成线程处理，不占用主线程，即使JS正在疯狂解析数据，动画也不会卡。

2.3 一个容易被忽略的设计决策：动画的“存在感”要匹配加载时长

这是我做了很多项目之后才总结出来的经验：加载动画的视觉强度应该和预期加载时长成正比。

如果加载只需要200毫秒，你放一个复杂的动画，用户根本看不清，反而觉得闪了一下很突兀。这种情况其实应该用骨架屏或者干脆不做动画，直接显示内容。如果加载需要2秒以上，那动画就要有足够的“内容”让用户觉得系统在干活，比如进度条、分步骤提示。如果加载时长不确定，可能5秒也可能30秒，那动画要能“循环但不烦人”，避免用户盯着一个重复动作产生焦虑。

这个决策直接影响实现方案。短时加载用CSS的animation配合animation-fill-mode就够了；长时加载可能需要JS来动态更新进度；不确定时长的加载则需要设计一个视觉上“有节奏感”的循环动画，让用户感知到系统还活着。

3. 核心细节解析：动画流畅的底层原理与关键参数

3.1 浏览器渲染管线：为什么你的动画会卡

要理解动画性能，必须知道浏览器把一帧画面画到屏幕上要经过哪些步骤。简化来说有五个阶段：

1. JavaScript：执行JS逻辑，修改DOM或样式
2. Style：计算每个元素最终生效的CSS样式
3. Layout：计算每个元素在屏幕上的位置和大小
4. Paint：把元素绘制成像素，填充颜色、阴影、文字等
5. Composite：把多个图层合成最终画面

关键来了：如果你动画修改的属性会触发Layout或Paint，那每一帧都要重新走这些步骤，开销巨大。而如果你只修改transform和opacity，浏览器可以跳过Layout和Paint，直接在Composite阶段处理，这就是所谓的“GPU加速”。

我举个具体的例子。你要让一个方块从左移到右：

/* 差的做法：触发Layout */ .box { transition: left 0.3s; } .box.move { left: 200px; } /* 好的做法：只触发Composite */ .box { transition: transform 0.3s; } .box.move { transform: translateX(200px); }

第一种写法每一帧都要重新计算布局，如果页面上元素多，直接掉帧。第二种写法浏览器直接把方块作为一个图层移动，丝滑得多。这个区别在简单页面上可能看不出来，但在复杂页面或者低端设备上就是天壤之别。

3.2 加载动画的核心参数：时长、缓动、循环

一个加载动画的“手感”由三个参数决定：时长（duration）、缓动函数（easing）、循环方式（iteration）。这三个参数的选择不是拍脑袋，背后有明确的逻辑。

时长方面，加载动画的单次循环建议在0.8秒到1.5秒之间。太短了看起来像抽搐，太长了用户会觉得系统反应慢。我实测下来，1秒左右的旋转周期是最舒服的，既能让用户感知到运动，又不会产生急躁感。

缓动函数是很多人忽略的重点。加载动画最忌讳用linear（匀速），因为匀速运动看起来机械、没有生命感。但也不能用ease-in-out这种两头慢中间快的，因为循环起来会有明显的“一顿一顿”的感觉。加载动画的最佳选择是cubic-bezier自定义一个接近匀速但略带加速减速的曲线，或者直接用linear配合视觉上的非对称设计来打破机械感。

/* 一个我常用的加载旋转缓动 */ @keyframes spin { from { transform: rotate(0deg); } to { transform: rotate(360deg); } } .loading { animation: spin 1s cubic-bezier(0.5, 0, 0.5, 1) infinite; }

循环方式上，infinite是加载动画的标配，但要注意animation-direction的选择。alternate（往返）适合脉冲类动画，normal（单向）适合旋转类动画。用错了会很奇怪，比如旋转用alternate会变成来回摆头。

3.3 合成层与will-change：什么时候该用，什么时候是坑

will-change这个属性被很多人当成性能优化的万能药，到处加。实际上它是一把双刃剑。will-change: transform会提前告诉浏览器“这个元素要动，给它单独开个合成层”。好处是动画启动时不需要临时创建图层，坏处是每个合成层都要占显存，加多了直接爆显存，反而更卡。

我的经验法则是：只在动画即将开始前加上will-change，动画结束后立刻移除。对于持续运行的加载动画，可以一直保留，但页面上同时存在的加载动画不要超过3个。如果是列表里每个item都有加载动画，那绝对不能每个都加will-change，否则合成层数量爆炸。

// 动画开始前 element.style.willChange = 'transform'; // 动画结束后 element.addEventListener('animationend', () => { element.style.willChange = 'auto'; });

还有一个细节：transform: translateZ(0)或者translate3d(0,0,0)也能强制开启合成层，效果类似will-change，但它是立即生效的。在移动端上，这个技巧曾经很流行，但现在更推荐用will-change，因为语义更清晰，浏览器也能更智能地管理。

3.4 加载动画的视觉设计要点：让等待不那么难熬

从实现角度讲，加载动画只要转起来就行。但从用户体验角度讲，一个好的加载动画要解决“等待焦虑”。这里有几个我验证过有效的设计要点：

第一，给一个“进度感”。即使你不知道具体进度，也可以用视觉暗示。比如一个旋转的圆环，如果它的缺口在变化，用户会潜意识觉得“快好了”。纯匀速旋转的圆环反而让人不知道要等多久。

第二，避免“无限循环”的绝望感。如果一个动画看起来会永远转下去，用户会烦躁。解决办法是让动画有“呼吸感”，比如周期性地加速减速，或者配合文字提示“正在加载，请稍候”，让用户知道系统在正常工作。

第三，加载完成后的过渡要干净。我见过太多项目，数据加载完了，加载动画直接display: none，内容“啪”地一下出现，很生硬。正确的做法是让加载动画淡出，内容淡入，中间有200毫秒左右的重叠过渡。

.loading { transition: opacity 0.2s; } .loading.hide { opacity: 0; pointer-events: none; } .content { opacity: 0; transition: opacity 0.3s; } .content.show { opacity: 1; }

4. 实操过程：从零实现一套完整的加载动画方案

4.1 基础旋转加载器的完整实现

先从最简单的开始。一个旋转圆环加载器，这是最通用的加载动画形式。我会把每一步的意图讲清楚。

<div class="spinner" role="status" aria-label="加载中"> <svg viewBox="0 0 50 50"> <circle class="track" cx="25" cy="25" r="20"></circle> <circle class="indicator" cx="25" cy="25" r="20"></circle> </svg> </div>

.spinner { width: 40px; height: 40px; } .spinner svg { animation: rotate 1.4s linear infinite; } .track { fill: none; stroke: #e0e0e0; stroke-width: 4; } .indicator { fill: none; stroke: #3b82f6; stroke-width: 4; stroke-linecap: round; stroke-dasharray: 126; stroke-dashoffset: 126; animation: dash 1.4s ease-in-out infinite; } @keyframes rotate { from { transform: rotate(0deg); } to { transform: rotate(360deg); } } @keyframes dash { 0% { stroke-dashoffset: 126; } 50% { stroke-dashoffset: 32; } 100% { stroke-dashoffset: 126; } }

这里有几个关键点。stroke-dasharray设为圆周长（2πr ≈ 125.6），stroke-dashoffset从126变到32再变回来，视觉上就是圆环的缺口在伸缩。配合外层的旋转，就形成了一个“追逐”效果，比单纯旋转更有动感。stroke-linecap: round让线条端点变圆，看起来更精致。

role="status"和aria-label是无障碍访问的基本要求，屏幕阅读器会读出“加载中”。这个细节很多开发者会漏掉，但它是专业度的体现。

4.2 骨架屏与加载动画的配合使用

骨架屏（Skeleton Screen）是加载动画的进阶形态。它不是在页面中央放一个转圈，而是用灰色块模拟内容的大致布局，让用户提前感知页面结构。实现上，骨架屏的核心是一个“闪烁”动画。

.skeleton { background: linear-gradient( 90deg, #f0f0f0 25%, #e0e0e0 37%, #f0f0f0 63% ); background-size: 400% 100%; animation: shimmer 1.4s ease infinite; } @keyframes shimmer { 0% { background-position: 100% 50%; } 100% { background-position: 0 50%; } }

这个shimmer动画的原理是：背景是一个横向的渐变，通过移动background-position让高光区域从左扫到右。background-size: 400%是为了让渐变足够宽，移动时不会露出边缘。这个动画只修改background-position，会触发Paint，但因为是纯色块，Paint开销很小，实测在低端机上也能跑满60帧。

骨架屏和转圈加载器可以配合使用：页面首次加载用骨架屏，局部刷新用转圈。骨架屏的灰色块尺寸要和真实内容一致，否则内容出现时会有跳动，反而体验更差。

4.3 用requestAnimationFrame实现一个进度驱动的加载动画

有些场景下，加载进度是已知的，比如文件上传、资源预加载。这时候用CSS动画就不合适了，因为进度是动态的，需要用JS来驱动。

class ProgressLoader { constructor(element) { this.el = element; this.progress = 0; this.displayProgress = 0; this.rafId = null; } setProgress(value) { this.progress = Math.min(100, Math.max(0, value)); if (!this.rafId) { this.rafId = requestAnimationFrame(() => this.render()); } } render() { // 缓动跟随，避免进度跳变 const diff = this.progress - this.displayProgress; this.displayProgress += diff * 0.15; if (Math.abs(diff) < 0.1) { this.displayProgress = this.progress; } this.el.style.transform = `scaleX(${this.displayProgress / 100})`; this.el.setAttribute('aria-valuenow', Math.round(this.displayProgress)); if (this.displayProgress !== this.progress) { this.rafId = requestAnimationFrame(() => this.render()); } else { this.rafId = null; } } }

这段代码的核心是缓动跟随。如果直接把progress赋给宽度，进度条会跳变，看起来很生硬。用displayProgress += diff * 0.15让显示进度平滑地追赶上真实进度，视觉上就顺滑多了。0.15这个系数是我调出来的，太小了跟不上，太大了会抖动，0.1到0.2之间比较合适。

requestAnimationFrame的使用要点是：只在需要更新时请求下一帧，更新完成后停止循环。不要无脑地一直requestAnimationFrame，那样即使没有变化也在空转，浪费CPU。

4.4 动画编排：多个元素的时序控制

复杂加载动画往往有多个元素按顺序运动，比如三个点依次跳动。这种时序控制用CSS的animation-delay就能实现，不需要JS。

.dots { display: flex; gap: 8px; } .dot { width: 10px; height: 10px; border-radius: 50%; background: #3b82f6; animation: bounce 1.2s ease-in-out infinite; } .dot:nth-child(2) { animation-delay: 0.15s; } .dot:nth-child(3) { animation-delay: 0.3s; } @keyframes bounce { 0%, 60%, 100% { transform: translateY(0); } 30% { transform: translateY(-12px); } }

这里的关键是animation-delay的间隔。三个点，总周期1.2秒，延迟分别0、0.15、0.3秒，这样它们不会同时到达最高点，形成波浪效果。延迟间隔一般是总周期的10%到15%，太小了看不出区别，太大了会显得脱节。

如果元素数量不固定，比如动态生成的列表项，那就需要用JS来设置animation-delay：

document.querySelectorAll('.dot').forEach((dot, index) => { dot.style.animationDelay = `${index * 0.15}s`; });

4.5 加载动画的退出：别让动画“烂尾”

加载动画的退出和进入同样重要。我总结了一个“三段式退出”方案：

1. 数据到达：触发退出逻辑
2. 动画淡出：加载动画在200毫秒内透明度降到0
3. 内容淡入：内容在300毫秒内透明度从0升到1，与淡出有100毫秒重叠

function finishLoading(loadingEl, contentEl) { loadingEl.classList.add('fade-out'); contentEl.classList.add('fade-in'); loadingEl.addEventListener('transitionend', () => { loadingEl.style.display = 'none'; }, { once: true }); }

.fade-out { opacity: 0; transition: opacity 0.2s ease; } .fade-in { opacity: 1; transition: opacity 0.3s ease 0.1s; }

注意transitionend事件要用{ once: true }，避免重复触发。另外，如果加载动画是display: none隐藏的，淡出动画不会生效，所以要先确保它是可见的，再改透明度。

5. 常见问题与排查技巧实录

5.1 动画卡顿的排查思路

动画卡顿是最常见的问题，排查起来要有章法。我一般按这个顺序查：

第一步，打开浏览器的性能面板录制一段。看帧率曲线，如果帧率掉到30以下，说明有问题。然后看主线程的活动，如果主线程被长任务占满，那动画肯定卡。

第二步，检查动画修改的属性。在性能面板里看每一帧的Layout和Paint耗时。如果Layout耗时很高，说明动画触发了重排，要改成transform或opacity。

第三步，检查合成层数量。在开发者工具的Layers面板里看有多少个合成层。如果几十上百个，显存压力大，要减少will-change的使用。

第四步，检查是否有强制同步布局。在动画循环里读取offsetWidth、getBoundingClientRect这类属性，会强制浏览器立即计算布局，打断优化。解决办法是把读取操作集中到动画开始前，或者用requestAnimationFrame分离读写。

// 差的做法：读写交替 element.style.transform = 'translateX(100px)'; const width = element.offsetWidth; // 强制同步布局 element.style.transform = 'translateX(200px)'; // 好的做法：先读后写 const width = element.offsetWidth; requestAnimationFrame(() => { element.style.transform = 'translateX(100px)'; });

5.2 加载动画不显示或显示异常的常见原因

5.3 几个我踩过的坑和独家技巧

坑一：animation简写属性覆盖了animation-delay。animation: spin 1s infinite这个简写会把animation-delay重置为0。如果你之前单独设置了animation-delay，简写会把它覆盖掉。解决办法是要么用完整写法，要么把animation-delay放在简写之后。

坑二：transform和animation同时作用于一个元素会冲突。如果你用JS设置了element.style.transform，同时CSS里又有animation修改transform，两者会打架。解决办法是把动画作用在父元素或子元素上，分离控制。

坑三：加载动画在页面隐藏时仍在运行。用户切到其他标签页，加载动画还在跑，浪费CPU。用document.visibilityState监听页面可见性，不可见时暂停动画。

document.addEventListener('visibilitychange', () => { const spinner = document.querySelector('.spinner svg'); if (document.hidden) { spinner.style.animationPlayState = 'paused'; } else { spinner.style.animationPlayState = 'running'; } });

技巧一：用prefers-reduced-motion尊重用户的系统设置。有些用户因为身体原因会关闭系统动画，你的加载动画应该响应这个设置。

@media (prefers-reduced-motion: reduce) { .spinner svg { animation: none; } .spinner::after { content: '加载中...'; } }

技巧二：加载动画的尺寸不要超过容器的一半。太大的加载动画会喧宾夺主，让用户觉得页面很空。一般控制在40到80像素之间比较合适。

技巧三：用CSS变量统一管理动画参数。项目里多个加载动画的时长、颜色应该统一，用CSS变量管理，改一处全生效。

:root { --loading-duration: 1.4s; --loading-color: #3b82f6; --loading-track: #e0e0e0; }

6. 动画性能优化的进阶手段

6.1 用Web Animations API替代CSS动画的时机

CSS动画简单好用，但有些场景下它的控制力不够。比如你需要动态改变动画速度、需要在动画中途暂停并获取当前进度、需要编排复杂的时序。这时候Web Animations API（WAAPI）是更好的选择。

const spinner = document.querySelector('.spinner svg'); const animation = spinner.animate([ { transform: 'rotate(0deg)' }, { transform: 'rotate(360deg)' } ], { duration: 1400, iterations: Infinity, easing: 'linear' }); // 动态调速 animation.updatePlaybackRate(2); // 暂停和恢复 animation.pause(); animation.play(); // 获取当前进度 console.log(animation.currentTime);

WAAPI的优势是动画对象是JS可操作的，能精确控制。而且它底层和CSS动画走的是同一套渲染管线，性能一样好。缺点是兼容性虽然已经很好，但在一些老设备上还是需要降级方案。

6.2 用CSS Houdini扩展动画能力

CSS Houdini的@property规则可以让你自定义CSS属性，并且让浏览器知道这个属性的类型，从而能对它做动画。这解决了一个经典问题：CSS无法对background: linear-gradient做动画，因为浏览器不知道渐变怎么插值。

@property --progress { syntax: '<percentage>'; initial-value: 0%; inherits: false; } .progress-ring { background: conic-gradient( #3b82f6 var(--progress), #e0e0e0 var(--progress) ); animation: fill 2s ease forwards; } @keyframes fill { to { --progress: 100%; } }

这个方案在支持Houdini的浏览器上能实现非常平滑的进度环动画，而且完全由CSS驱动。不支持的环境需要降级到SVG方案。目前主流浏览器的新版本都已经支持，可以作为渐进增强来用。

6.3 加载动画的懒加载与销毁

单页应用里，加载动画组件如果频繁创建销毁，会有性能开销。我的做法是复用同一个加载动画实例，通过显示隐藏来控制，而不是每次都重新创建DOM。

class LoadingManager { constructor() { this.el = this.createLoader(); document.body.appendChild(this.el); this.activeCount = 0; } createLoader() { const el = document.createElement('div'); el.className = 'global-loading'; el.innerHTML = '<div class="spinner"></div>'; el.style.display = 'none'; return el; } show() { this.activeCount++; this.el.style.display = 'flex'; } hide() { this.activeCount = Math.max(0, this.activeCount - 1); if (this.activeCount === 0) { this.el.style.display = 'none'; } } }

用引用计数管理加载状态，避免多个异步请求同时进行时，一个完成了就把加载动画关掉，导致其他请求还在跑但用户看不到反馈。这个细节在真实项目里非常关键，我见过不止一个项目因为这个问题导致用户以为操作完成了，实际上后台还在加载。

7. 不同场景下的加载动画选型建议

7.1 首屏加载、局部刷新、长任务加载的差异化方案

首屏加载：用户第一次打开页面，白屏时间越长流失率越高。这个场景下，加载动画要尽早出现，最好在HTML里内联一个简单的CSS动画，不等JS加载完就能显示。骨架屏是首选，因为它能让用户提前看到页面结构。如果做不了骨架屏，就用一个居中的简单旋转器，颜色用品牌色，尺寸稍大一些。

局部刷新：比如列表下拉刷新、按钮点击后的等待。这种场景下，加载动画要出现在操作发生的局部区域，而不是全屏遮罩。按钮上的加载动画通常是把按钮文字换成一个小旋转器，或者按钮右侧出现一个旋转器。列表刷新则是在列表顶部出现一个下拉指示器。

长任务加载：比如文件处理、数据导出。这种场景下，用户需要知道进度和预计时间。进度条加百分比文字是最佳选择。如果进度无法精确计算，就用一个“不确定进度”的动画，比如来回移动的条，配合“正在处理，请稍候”的文字。

7.2 移动端与桌面端的加载动画差异

移动端和桌面端的加载动画在实现上要注意几个差异点：

触摸反馈：移动端上，加载动画出现时往往伴随着用户的触摸操作。要确保加载动画不会阻挡用户的触摸事件，或者明确地阻止重复操作。pointer-events: none可以让加载动画不拦截点击，但如果是全屏遮罩，反而应该拦截点击防止重复提交。

性能预算：移动端的GPU和CPU资源比桌面端紧张得多。在移动端上，合成层的数量要严格控制，动画元素要尽量小。我实测下来，移动端上同时运行的加载动画不要超过2个，每个动画的元素面积不要超过屏幕的10%。

电量消耗：持续运行的动画会耗电。如果加载时间可能很长，考虑在用户一段时间没有交互后降低动画帧率或暂停动画。这个优化在桌面端不重要，但在移动端上对续航有实际影响。

7.3 无障碍与加载动画的兼容

加载动画对屏幕阅读器用户是不可见的，所以必须提供文字替代。role="status"配合aria-label是最基本的。更进一步，可以用aria-live区域动态播报加载状态。

<div aria-live="polite" class="sr-only"> 正在加载数据，请稍候 </div>

sr-only是一个视觉隐藏但屏幕阅读器可读的类。当加载状态变化时，更新这个区域的文字，屏幕阅读器会自动播报。这个细节在面向公众的产品里是必须的，在内部系统里也建议加上，成本很低但体现了专业度。

8. 我个人的实操体会与建议

做了这么多年的动画和加载效果，我最大的体会是：动画的质量不取决于技术多复杂，而取决于细节多到位。一个简单的旋转器，如果缓动曲线调对了、退出过渡做顺了、性能优化到位了，比一个花哨但卡顿的复杂动画要好得多。

另外，我强烈建议在项目里建立一套动画规范，把常用的加载动画、过渡时长、缓动函数统一管理起来。不要每个开发者各写各的，最后项目里出现五六种不同风格的加载动画，用户会觉得产品很散。用CSS变量或者设计令牌（Design Token）的方式统一管理，改一处全生效。

最后分享一个小技巧：在开发阶段，把加载动画的时长调慢3倍，这样你能看清每一帧的运动轨迹，更容易发现缓动曲线的问题。上线前再调回正常速度。这个习惯帮我发现了很多肉眼在正常速度下看不出来的动画瑕疵。

这个内容后续还可以这样扩展：把加载动画和错误状态、空状态结合起来，形成一套完整的“异步状态反馈体系”。加载中、加载成功、加载失败、无数据，这四种状态的视觉语言应该是一脉相承的，用户看一眼就知道当前是什么情况。这个体系建好了，整个产品的完成度会提升一个档次。