蓝牙连接成功之后：App 与设备还要对齐哪些状态
连接图标亮起，不代表业务已经准备好。围绕准备、执行、暂停、断连与恢复，梳理 App 和固件协作时容易漏掉的细节。
在智能硬件项目里，“已经连上蓝牙”经常被当成联调完成的标志。真正开始使用后，问题却可能出现在另一个层面：App 认为设备准备好了，固件仍在初始化；用户按了暂停，界面先变了，设备却没有确认。解决这些问题，首先需要一份双方都能执行的业务状态说明，而不是再加一个连接动画。
区分连接状态与业务状态
可以把“正在连接、已连接、已断开”看成连接层信息；把“初始化、就绪、运行、暂停、结束、异常”看成业务层信息。它们的关系要由项目定义：连接建立后读取哪些信息、是否校验固件能力、什么时候开放开始按钮。不要让用户靠多按几次按钮来碰运气。
命令发出，不等于动作完成
为关键操作约定请求编号、确认结果、失败原因和等待期限。界面可以先展示“正在开始”，在设备确认之后进入运行态。发生超时后，应先判断设备当前状态，再决定是否重试。对于开始、停止等操作，尤其要明确重复请求如何处理，避免把同一动作执行多次。这里说的是业务协议设计，不能只依赖底层连接状态来代替。
| 场景 | App 需要知道 | 设备需要明确 |
|---|---|---|
| 首次连接 | 能力、版本与当前业务状态 | 初始化是否完成 |
| 开始互动 | 命令是否被接受 | 是否具备执行条件 |
| 运行中断连 | 是否暂停、如何提示 | 继续、停止或进入保护状态的规则 |
| 重新连接 | 如何恢复真实状态 | 返回当前状态及必要记录 |
| 异常结束 | 原因与下一步操作 | 清理执行状态与错误标记 |
先约定断连策略，再做恢复界面
断连后继续还是停止，取决于产品用途与风险判断，不适合套用统一答案。团队应逐项讨论设备执行是否依赖实时指令、手机不在时用户能否独立停止，以及恢复连接后是否允许接着运行。确认策略后，再设计提示文案与操作入口，让用户知道设备现在处于什么状态。
用异常路径做一次联合验收
- 设备运行时主动离开连接范围，再返回。
- App 切换到后台、被系统结束后重新打开。
- 连接过程中连续点击开始或返回。
- 固件与 App 使用不匹配的版本进行连接。
- 设备在低电量或错误状态下收到开始命令。
每次测试保留 App 日志、设备日志、请求编号和发生时间。不要只记录“偶尔连不上”。如果双方没有共同时间参考，也可以通过同一请求编号对齐事件顺序。验收报告应写清预期行为与实际行为，并把修复后的结果补回相同场景。
对用户来说，可靠的连接体验意味着：他能知道设备在做什么，也能在意外发生后找到明确的下一步。