状态 State

State 记住的是页面当前事实；这里用订单配送作为案例，订单会从待发货进入配送中，最后停在已送达，用户再次进入仍能看到最新阶段。

• 开始时：订单已经确认，当前状态是待发货。
• 完成后：包裹已送达，订单仍保留已送达状态。

先看用户是在订单支付状态案例中填写、选择、移动还是执行动作：按钮 Button ≠ 事件 Event，外观相似也不代表职责相同。

• 如果用户要完成支付订单，页面必须把触发方式和结果说清楚。
• 在订单支付状态里，只在订单状态附近保留当前任务的状态和反馈。

看订单详情里的真实界面：每个标注都对应一个页面部件，不用图片坐标猜位置。

• 结构预览保持只读；这里重点看订单标题、当前状态、支付动作和结果反馈如何组成当前界面。
• 订单卡片本体只做静态结构展示，编号和说明行负责定位对应部件。

State 的变体比较同一个状态值在不同组件形态中的呈现，不把处理中或成功流程误当成变体。

• 行内徽标、对象卡片和时间线节点分别对应不同的信息密度与空间关系。
• State 的业务成功、失败和网络反馈放到 Behavior Scenario。

收藏文章后，阅读卡只保留当前收藏事实，按钮负责触发一次局部更新。

• 初始是未收藏；点击收藏文章后，按钮进入保存中。
• 完成后显示已收藏，重新演示回到未收藏。

状态 State什么时候用、什么时候不用？先看任务边界，再看组件外观。

• 什么时候用：收藏后页面要保留“已收藏”状态，重新进入时也能展示当前值。
• 什么时候不用：总价可以由商品和数量计算出来，不要再维护一个容易不同步的副本。

怎么判断：先看用户要完成的任务和内容关系，再选择职责准确的组件。

请使用共享 State 组件实现订单支付案例：State 负责记住订单当前事实，不把概念缩减成颜色；保留待支付、支付处理中和已支付三个真实状态，并让已支付状态在下次进入时可复查。失败时保留当前订单状态和可重试入口，不要用 iframe、手写控件外观或硬编码颜色。