


1/4
Day 07 · Skeleton Screen:内容加载时的占位幽灵
June 16, 2026 · 9:12 AM
Gallery
界面在加载,但用户还没走——骨架屏做的就是这件事:用和真实内容同形的灰色占位结构,让等待本身变得有意义。
这一期讲什么
Skeleton Screen(骨架屏)是 Loading Spinner 的进化版本。Spinner 只告诉用户「系统在转」,骨架屏进一步告诉用户「即将出现的是什么形状的内容」。两者都在等,感受却截然不同。
封面
三兄弟对比:Skeleton Screen / Spinner / Progress Bar
三者最常被混用,核心区别只有一句话:
- Spinner:进度未知,内容形态未知,只知道「在处理」
- Skeleton Screen:进度未知,但内容形态已知,用占位骨架暗示即将出现的是什么
- Progress Bar:进度可量化,能告诉用户完成了多少
适合 Skeleton Screen 的场景,是那些你知道要加载的是「一组卡片」「一个列表」还是「一篇文章」——内容形态可预知,骨架才能和真实内容匹配上,加载完成瞬间才不会「跳」。
4 种常见骨架屏模板
不是所有内容都用同一套骨架,根据真实内容结构来:
- 卡片骨架(Card Skeleton):顶部图片占位块 + 标题条 + 正文条,适合电商卡、内容卡
- 列表骨架(List Skeleton):每行左侧圆形头像占位 + 右侧双线条,适合新闻流、评论区
- 文章骨架(Article Skeleton):一条宽标题条 + 多行正文条,适合详情页、博客
- 个人资料骨架(Profile Skeleton):圆形头像 + 居中名字条 + 统计块,适合用户主页
骨架的结构越接近真实内容,加载完成时的视觉「接力」就越顺滑。
该用 vs 别用
该用的场景:
- 内容结构已知(卡片 / 列表 / 文章)
- 加载时长预计 > 300ms
- 首屏大量内容同时加载
- 用户反复访问、对内容形态熟悉
别用的场景:
- 内容结构完全不可预测
- 加载 < 300ms(骨架一闪而过比空白更烦)
- 只有单个按钮或图标在加载
- 骨架形态和真实内容差异太大,出现感知断裂
判断口诀:能量化 → Progress Bar,不能量化 → Spinner,加载内容列表 → Skeleton Screen
交互反馈类 7 个组件,今天讲完了最后一个。明天起换表单组件类:Input、Checkbox、Toggle……那一块的「边界感」问题其实更多。

Comments