六种让应用“显得快”的加载状态

“快”是一种感觉

两个应用同样花 800ms 加载，体验可能天差地别——差别在于等待时用户看到什么：一片惨白的屏幕读作“坏了”，微微闪动的骨架屏读作“在干活”。感知性能是你能上线的最便宜的性能优化。

六种模式，各自的使用时机

• 骨架屏 shimmer——用于形状可预期的等待（信息流、卡片、看板）：布局先占住，数据来了不跳版。
• 轨道 spinner——用于一秒内的动作（保存、发送）：小、内联、绝不全屏。
• 液态 / blob 加载器——品牌时刻专用：新手引导、有个性的上传。一个应用用一个，不要每页都用。
• 确定性进度条——超过约 3 秒的等待。会走的进度条胜过任何 spinner，因为它承诺了终点。
• 乐观 UI——最好的加载是不加载：立即渲染成功态，失败再回滚。
• 交错进场——数据到达时别一次全闪出来，让行以 200ms 级联进场。

区分专业与业余的那条规则

永远别让加载器出现少于约 300ms。闪现 80ms 的 spinner 读作 bug。给加载器加延迟：只有等待超过 300ms 才出现，并淡入——这一个细节就是“感觉秒开”和“感觉卡顿”的分界线。

第二条：加载态要诚实。为 50ms 的请求硬造 500ms 的骨架屏，你是为了显得快而真的变慢了。骨架屏只为真实等待服务。

抄走就行，不用自己设计

加载状态本质是编排——时间曲线和透明度。这使它们成为完美的 Prompt 素材：描述等待，而不是描述像素。