R1.03.2missing data-state trio设计
加载、空、错误状态最常缺失
别名: 加载空错误 · data states · 内容状态缺口
概念解释
组件稿几乎总是对着「已经有数据、而且是对的」那一帧来画，所以最常缺的不是悬停，而是加载、空、错误这一组内容状态。三者共享一个结构：组件此刻没有可用的正经内容，画布上就没有东西可画，于是这一帧从文件里消失。
缺的是组件自己在这三种情况下的外观与文案槽位，不是空状态该如何引导用户去完成第一次任务——那是交付层的另一件事。这里只认定：这三格最容易从组件规格里漏掉。
机制
交互状态由用户的指针和键盘触发，设计时只要把鼠标移上去就能看见；内容状态由网络、空集和失败回调触发，静态画布默认假定数据已在。列表、卡片、选择器和输入建议都是先画满的，加载圈、空槽、错误条要另开一帧，而这一帧不挡住主流程评审，就被排到「有空再补」。
三个状态还会被误当成页面级问题，从组件规格里踢走：加载被交给全局骨架，空被交给整页空白，错误被交给 toast。结果是同一个选择器在下拉中加载、在筛选结果里为空、在提交后报错，三处各写各的，组件作为单位仍然没有这三格。漏掉的原因不是不知道它们存在，而是它们在画布上没有自然的触发器。
边界
永远同步、本地写死、不可能失败的装饰性片段（固定的站点页脚）可以没有这三格。流式内容的「还在追加」不同于首次加载，不能拿转圈顶掉已有列表。权限不足导致的空和查询无结果的空含义不同，若组件只提供一个空槽，至少要能插入不同文案，不能假装只有一种空。错误若必须由页面级横幅统一承接，组件可以不画自己的错误条，但规格里要写明「错误不在本组件内」，不能省略成没这回事。
怎么落地
- 每个会取数据或提交数据的组件，在状态表里固定加上加载、空、错误三行，哪怕某行的结论是「由父级承接」。
- 三行都要有真实文案槽和尺寸：骨架要接近最终内容形状，空要有主句，错误要有可重试或可定位的说明。
- 用慢网、空查询、强制失败各走一次主路径，确认三帧都会出现，而不是闪成空白。
- 验证：打开该组件的设计文件和 Storybook，三行都有独立故事。缺故事的那一行，就是最常被漏掉、现在仍被漏掉的那一格。