结构可预知时用骨架屏
别名: 可预知结构用骨架 · 模板已知选骨架 · predictable layout skeleton
概念解释
等待指示要先做一次选型，不是先挑一种好看的组件。当即将到来的界面有一份在数据到达前就存在的模板——列表行、资料头、文章栏、固定栅格的卡片墙——正确的等待语言是骨架屏（skeleton screen），不是转圈。选型问的是：系统能不能在载荷回来之前诚实说出「东西会落在这些位置」。能，就用骨架把等待填进即将出现的几何里；不能，转去不确定指示，那是下一叶的事。
这条不解释骨架色块怎么画，只判定：结构可预知，是选用骨架的准入条件。
机制
一次等待里人同时要两份信息：系统还在工作，以及即将占据屏幕的是哪种东西。转圈只答第一问。骨架把第二问也答了，代价是必须先有一份不依赖本次载荷的结构知识：路由对应哪种页面、权限会不会拆掉整块、列表是不是固定行高。这些知识来自产品自己的模板，不是来自这一次网络包。
可预知不等于内容已知。标题写什么、头像是谁，都可以空着；空着的是槽位。槽位在模板里已经编号，视觉系统就能提前把屏幕划成「这里会有标题、这里会有一排」。划完之后，到达不再是从空白里突然冒出物体，而是物体落入已划好的槽。转圈做不到这步预演，所以在结构已知时用转圈，是把已经有的结构知识浪费掉，让等待停留在「有个循环在转」。
边界
可预知是对这一次等待说的。同一产品里，资料页可预知、搜索结果不可预知，不能全局规定「我们用骨架」。权限、实验分组、用户自定义模块会在载荷里才揭晓时，模板只是一种猜测，骨架的准入条件不成立。生成式内容、对话流、高度依赖查询词的结果页，结构随输入变，预知失败。极短等待里骨架还没站稳就结束，选型本身会制造闪烁，不该为了「结构已知」强行入场。骨架表达结构，不表达还剩多少；总量已知且等待会越过注意力窗口时，骨架之外还需要进度，不能拿骨架当百分比的替代品。
怎么落地
- 按路由和模板做一张选用表：能在没有载荷的情况下画出主区块的页面，等待默认骨架；画不出的，不要为了统一视觉强上骨架。
- 骨架只承诺这次等待真正稳定的部分：固定的头、固定的列、固定的行高。会随数据出现或消失的模块不要画进去充数。
- 不要用「品牌转圈」覆盖结构已知的列表和文章——转圈可以留在结构未知的动作上。
- 验证：关掉网络，只根据当前 URL 和登录态，让另一个人在纸上标出加载完成后的主要块。标得出来，用骨架；标不出来，这条的准入没满足。