一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 三个布尔量已经能组成八种组合，其中多数没有业务含义。异步回调又可能乱序修改它们，最终出现“已连接且正在连接”或“已停止但仍重试”。状态机让允许的转换成为代码契约。
前端架构的核心不是目录层级，而是状态由谁拥有、事件能否重复执行、旧异步结果如何失效，以及卸载后监听器和资源是否真正归零。
设计时必须回答的问题
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 先列出稳定状态、瞬态和终态，每个事件只允许从明确来源状态进入。
- 副作用在进入或退出动作中启动，并用状态版本取消旧异步回调。
- UI 从单一状态派生按钮、提示和禁用条件，不再维护第二套布尔真相。
状态机不是为了画图，而是把竞态从“碰巧没发生”变成可拒绝的非法转换，让界面、副作用和持久化共享同一事实。
边界情况不是附加项
边界条件会把隐藏假设变成真实事故。弱网、刷新、并发和容量上限必须组合测试，因为单独出现时它们往往都能被重试掩盖。
- 收到旧 session 的 connected 事件，把已经 stopped 的状态重新变在线。
- 失败状态没有保存失败阶段和可重试性，所有错误都回到同一个 idle。
- 为了修一个边界直接强制赋值状态，绕开转换守卫和清理动作。
用证据确认它真的可用
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 生成所有事件与状态组合，断言非法转换不改变状态且留下诊断。
- 随机排列超时、同意、拒绝、关闭和重连事件，最终状态必须可解释。
- 从每个瞬态刷新页面，持久恢复只能进入定义好的恢复入口。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。