组件状态不是“多画几张图”，而是组件的默认要求：凡是用户能点、能填、能等待的地方，都要回答它在各种情况下长什么样、能不能操作、失败之后怎么办。把状态写进组件规范，评审时才能逐项确认，而不是等开发实现完才发现少了一半。
本文只讨论组件级状态与变体；如果你要解决的是整页的空状态、无权限和错误页，可先参考后台管理系统的空、错、加载与无权限状态设计，那是页面级的范围。
只画一个正常态，会在三处返工
| 问题 | 常见表现 | 代价 |
|---|---|---|
| 可点性没有定义 | 按钮在无权限或数据不完整时仍然可点 | 上线后由前端临时决定，各处规则不一致 |
| 等待没有反馈 | 点击后页面没变化，用户重复提交 | 产生重复数据，还要人工清理 |
| 失败没有出口 | 错误只提示一句话，没有重试或修改入口 | 用户卡住，只能靠客服兜底 |
先分清页面状态和组件状态
两者容易混在一起。页面状态回答“这一页现在能不能完成任务”，例如列表为空、无权限、整体加载失败；组件状态回答“这一个控件此刻能不能操作、操作后如何反馈”。
划分清楚的好处是责任明确：页面状态由信息架构和流程决定，组件状态由组件规范决定。一个按钮的禁用规则应该在组件层写清楚，而不是每个页面各写一遍。
按组件类型列最小状态集
不必给所有组件配齐所有状态。先确定每个组件“最少要有哪些状态”，剩下的按业务补充。
| 组件 | 必需状态 | 按需补充 |
|---|---|---|
| 按钮 | 默认、悬停、按下、禁用、加载 | 危险操作、次要样式、仅图标 |
| 输入框 | 默认、聚焦、已填、禁用、校验失败 | 只读、带单位、可清空、字数超限 |
| 下拉与选择器 | 占位、已选、展开、禁用、无匹配结果 | 多选、可搜索、分组 |
| 表格行 | 默认、悬停、选中、禁用、批量操作中 | 展开行、内联编辑、异常标记 |
| 卡片与列表项 | 默认、悬停、选中、骨架加载 | 拖拽中、置顶、已读 |
| 开关与勾选 | 开、关、禁用、保存中 | 半选、仅读、权限受限 |
如果画的时候发现某个状态自己都说不清触发条件，说明需求还没写完，先回到业务规则，而不是先画图。
状态设计的四条规则
- 可点性与规则一致：同一个组件在不同页面的禁用条件应来自同一条业务规则，不能一处允许、一处禁止。
- 反馈时机明确：点击后立即出现加载提示，还是等接口返回再提示，要写清楚，避免用户重复操作。
- 文案和图标成对：状态变化同时用文字和视觉区分，不能只靠颜色，色弱用户和灰度打印会丢信息。
- 失败必须可恢复：错误提示要说清原因和下一步，并提供重试、修改或返回的入口。
这四条规则要同时写进需求文档和组件规范才可能被验收；需要把需求、原型和实现逐条对齐时，可参考PRD、原型和代码如何保持一致里的三向对照方法。
变体与状态的区别
两者都会让组件“长得不一样”，但管理方式完全不同。混淆的直接后果是组件数量失控：把状态当变体做，或者把变体当状态做，都会让维护成本翻倍。
| 维度 | 状态 | 变体 |
|---|---|---|
| 回答的问题 | 此刻能不能操作、结果如何 | 这一版外观用在什么场景 |
| 典型例子 | 禁用、加载、校验失败 | 主按钮与次按钮、紧凑与宽松 |
| 是否随交互变化 | 会，由用户操作或系统数据驱动 | 通常不会，由使用场景决定 |
| 改动成本 | 影响交互规则，需要回归验证 | 影响视觉表达，通常可局部调整 |
变体怎么收敛
新增变体之前先问一句：这个差异是“场景不同”还是“状态不同”。场景不同才做变体，状态不同应该用状态表达。
| 情况 | 建议做法 |
|---|---|
| 同一位置的主次操作 | 做成两个变体，明确使用场景 |
| 可点击与不可点击 | 用禁用状态，不要新建变体 |
| 只有颜色不同、结构一致 | 用变量控制色值，减少变体数量 |
| 业务字段差异很大 | 拆成两个组件，而不是塞进一个变体 |
收敛变体的前提是团队已经有稳定的复用基础，后台原型组件库怎么用用用户管理页示范了从选库到页面搭建的完整过程。
异步态：加载、骨架与防重复提交
涉及接口的地方至少要想清楚三件事：等待时显示什么、失败时保留什么、重复点击怎么办。局部刷新优先用行内加载或骨架，不要整页白屏；提交类操作在请求返回前应保持禁用或加载状态，避免重复提交。
加载状态的时间阈值也值得写进规范：短请求不闪骨架，超过一定时长再出现加载反馈，能明显减少界面跳动。
错误态的三个层级
把错误分成字段级、表单级和系统级，处理方式才不会互相打架。字段级错误贴在该字段下方并保留已填内容；表单级错误说明哪些项需要修改；系统级错误提供重试并说明数据是否已保存。三者都不要只弹一个笼统的提示。
组件状态与变体清单
| 维度 | 检查项 |
|---|---|
| 状态覆盖 | 每个可交互组件都有默认、禁用、加载与失败反馈 |
| 可点规则 | 禁用条件来自业务规则，并在各页面保持一致 |
| 反馈时机 | 等待、成功、失败三种反馈的触发时机已写明 |
| 错误恢复 | 字段、表单、系统三级错误都有恢复入口 |
| 变体收敛 | 仅颜色差异用变量，场景差异才新增变体 |
| 评审可用 | 关键状态能在原型中逐个走通，而不是只有静态图 |
落到工具里，可以在墨刀设计里用组件和变量统一规范，并按需补充选中、禁用等状态；需要评审时，按产品原型制作流程把关键状态串成可点击的流程，比逐张看图更容易发现遗漏。需要注意，代码生成结果仍需接入真实数据、业务逻辑和接口并完成测试。
常见问题
每个组件都要画全部状态吗？
不必。先保证“可交互组件至少覆盖默认、禁用、加载、失败”，其余状态按真实业务补充；没有任何触发条件的稀有状态先不画，等需求出现再补。
组件状态该写在需求文档还是组件规范里？
两边都要，但分工不同：需求文档写业务触发条件，组件规范写状态的表现与交互规则。需求里出现新状态时，先判断它应该回到规范，而不是在页面里单独画一个特例。
状态和变体的数量怎么控制？
状态数量由业务规则决定，只能精确不能省；变体数量应主动收敛，能用变量和属性表达的差异就不要新增变体。变体长期失控会直接拖慢交付，治理方法可参考组件库版本、复用与废弃策略。
总结
组件状态决定用户能不能顺利完成任务，变体决定界面在不同场景下的表达方式。先把最小状态集按组件类型列出来，再用四条规则校正可点性、反馈、文案和错误恢复，最后用变量和属性收敛变体数量。评审时把关键状态真正走一遍，比看静态稿更能提前发现问题。
