占位骨架的形状要与最终内容对应
别名: 骨架对形 · skeleton as content stand-in · 交付骨架契约
概念解释
交付包里的骨架不是一张「正在加载」的装饰图，而是最终内容的替身。骨架对形（content-matched skeleton）要求交出的等待帧在块的数量、相对位置、大致高度上能被最终内容帧逐块认领：头像圈对头像、标题条对标题、主按钮对主按钮。交一张通用灰条网格，实现就会做成通用灰条；内容到达时再对不上，那是交付时没把替身画成那份内容。
它回答的是这份等待画面作为发运物画的是谁，不是该用骨架还是转圈，也不是错配会如何在到达瞬间造成跳变——那些是选用与感知的问题。这里只要求：若决定要交骨架，骨架必须能指回同一份内容帧。
机制
实现会把交付里的骨架图层翻译成占位节点。图层是三行等宽灰条，节点就是三行等宽灰条，即使最终内容是左头像、右两列元信息加一颗操作。等待期间的几何一旦进了代码，到达后的第一帧只能去迁就或推翻这套节点；两种都贵，而且都发生在交付之后。对形把「将来长这样」写进等待帧，占位节点从一开始就按内容的骨架生长，到达时只替换材质，不替换结构。
对形不是描摹每一个字号。它钉的是人用来定向的锚：第一行文字的垂直位置、主操作的落点、侧栏在不在。锚对上了，灰块圆角差一点仍能被认领；锚没交，实现会用组件库里那套「列表骨架」去套仪表盘，仪表盘的到达帧再怎么精致也要先打一架。交付漏掉内容帧与骨架帧的并置，对形就无从检查，只能靠联调时的感觉。
边界
内容结构要到响应返回才知道（搜索结果有时是图墙、有时是表格）时，不要交一张假装知道的骨架；这类槽位的等待交付应是不确定指示，硬对形是假契约。骨架只覆盖本轮等待能兑现的块：会按权限消失的侧栏，不要画进默认骨架。极短等待若产品选择不画等待帧，就没有骨架可对，不要为了齐全补一张永不出现的图。广告、第三方嵌入若尺寸不由产品决定，骨架只能对产品自己的壳，不能对嵌入物内部排版。打印、导出没有等待帧，这条管不到。
怎么落地
- 把内容到达帧和骨架帧放在交付的同一页，用编号或叠层标出每一块的对应关系；没有对应编号的灰块删掉。
- 骨架只画锚点块：标题带、第一行、主按钮、固定侧栏。不要为了「看起来满」预画会随数据增减的行。
- 结构分叉（有图/无图、有侧栏/无侧栏）时，要么等到分叉揭晓再交对应骨架，要么在揭晓前不交骨架。
- 把两帧做成半透明叠图。标题带错位、主按钮在等待期和到达后不在同一坐标、或骨架多出内容里没有的一栏，都是对形失败。改骨架帧去就内容帧，不要在实现里给灰条加过渡动画来遮错位。