骨架屏表达即将出现的内容结构
别名: 占位骨架 · placeholder UI · 灰块加载
概念解释
骨架屏（skeleton screen）用低对比的色块按即将到来的内容排好位置：标题的一条、头像的圆、正文的几行。它不是转圈，也不是进度条。转圈只说「还在等」，骨架说的是「等的是这种结构的东西，而且会占这些位置」。它的工作窗口是内容即将到来、结构已经能确定的那段时间。结构还完全不知道时，画骨架等于在猜；那已经越界到后面两条。
机制
等待时人会问两件事：还在工作吗、来的是什么。转圈回答第一问；骨架用布局预演回答第二问，让视觉系统提前把区域划分成「将有标题 / 将有列表 / 将有图」。预演降低了内容到达时的定向成本：注视已经停在将来的标题位置，不必等真实文字出来再重新搜。骨架还把空白从「坏了」里救出来——同样一段时间的白屏会被读成没有内容或崩溃。它依赖的前提是结构可预测：卡片列表、个人资料头、文章正文，这些模板在数据回来之前就已经存在。不可预测的结构无法被预演，骨架就变成谎言的草稿。
怎么研究
同一段等待里比较白屏、转圈和骨架，再测量内容到达后找到目标信息的时间。
自变量：骨架与最终布局的符合程度、等待时长、内容类型（列表 / 文章 / 仪表盘）。 因变量：主观等待、到达后首次定位目标的时间、是否把骨架误认为已经加载完的残缺内容。
实验室里被试知道「这是加载」，不太会把灰块当成坏掉的正文。产品里更危险的是：骨架停得太久，用户开始试着点那些色块。要记误击，不只记「觉得快不快」。
边界
结构随用户而变的页面（自定义仪表盘、权限不同则模块不同）在数据回来前无法诚实预演，骨架会承诺不存在的块。极短等待里骨架闪一下反而比什么都不出更吵，那是加载指示器那一组要处理的时序。骨架表达的是结构不是进度，不能靠把色块从左涂到右来假装百分比。对屏幕阅读器，骨架通常没有等价物，应另有「正在加载」的状态，不能假设灰块也被读到了。
怎么落地
- 只在模板已知时用骨架：列表行、资料头、文章栏，按真实栅格画色块，而不是画一套通用波浪。
- 骨架要能看出区块种类（图、标题、行），不要用无法对应任何控件的抽象矩形。
- 加载结束时用骨架的坐标承接真实内容，让结构承诺被兑付。
- 验证：截下骨架和加载完成的第一帧叠在一起。主要块对不齐，骨架就没在表达即将出现的结构。