复杂 UI 状态交互需要穷尽覆盖时…

当组件或流程有多个相互影响、必须穷尽覆盖的状态时，用状态、事件、转换、动作和守卫建模为有限状态机。

适用场景

解决思路

1. 将组件或流程建模为有限状态机，明确 States（状态）、Events（事件）、Transitions（转换）、Actions（动作）、Guards（守卫）。
2. 定义 States：列出 UI 可处的不同模式，例如 idle（空闲）、loading（加载中）、success（成功）、error（错误）。
3. 定义 Events：列出引发转换的事件，例如 click（点击）、submit（提交）、timeout（超时）、response（响应）。
4. 定义 Transitions：写出移动规则，例如在状态 A 遇到事件 X 时转到状态 B。
5. 定义 Actions：为转换中的副作用命名或实现，例如 fetch data（获取数据）、show toast（显示提示）、log event（记录事件）。
6. 定义 Guards：为转换添加必须为真的条件，例如 isValid、hasPermission。
7. 采用或参考表单状态机模式：idle（空闲）-> editing（编辑中）-> validating（校验中）-> submitting（提交中）-> success/error（成功/错误）-> idle（空闲）。
8. 采用或参考数据获取状态机模式：idle（空闲）-> loading（加载中）-> success/error（成功/错误），error（错误）-> retrying（重试中）-> success/error（成功/错误）。
9. 采用或参考认证状态机模式：logged-out（已登出）-> authenticating（认证中）-> logged-in（已登录）-> logging-out（登出中）-> logged-out（已登出）。
10. 采用或参考多步向导状态机模式：step1（步骤1）-> step2（步骤2）-> step3（步骤3）-> review（审核）-> submitting（提交中）-> complete（完成）。
11. 列出所有可能状态。
12. 列出所有事件/触发器。
13. 定义有效转换。
14. 识别要防止的不可能状态。
15. 为条件转换添加守卫。
16. 为每个状态定义 entry/exit 动作。
17. 先建模 happy path（正常路径），再补充错误状态。
18. 确保每个状态都有出路，避免 dead ends（死胡同）。
19. 保持状态机聚焦，每个关注点一个状态机。
20. 用可视化图表记录状态机。
21. 把每个状态映射到对应的 UI 表现。

适用边界 · 注意事项

• 只关注单个交互的手感与反馈时，不适用；应使用 micro-interaction-spec。
• 组件状态很少、没有相互影响，或不需要穷尽状态空间时，不必使用状态机。