599 字
3 分钟
一个开关背后：本地控制与云端同步的边界
在一个多端继电器应用里，几个界面同时显示 ON，看起来像是一件很简单的事。但只要设备、网络或者客户端中的任何一环出了问题，就必须回答：这个 ON 到底代表什么？
先把两条链路分开
USB Relay Cloud 的 V1 定位是本地控制、云端记录与实时同步。用户在连接硬件的客户端操作，客户端通过 USB 串口发送指令。写入成功后，再向云端上报事件。
云端保存事件，并通过 WebSocket 广播给其他客户端。其他端更新界面，展示最近一次指令。这个流程里，操作硬件的入口仍然在本地客户端。
- 控制链路：本地客户端 -> USB 串口 -> CH340 -> 继电器。
- 同步链路：本地客户端 -> REST 接口 -> 数据库 -> WebSocket -> 其他客户端。
云端最后指令，不是物理反馈
串口写入成功，表示软件层成功提交了这条指令。它本身不能证明继电器触点已经按预期动作。没有额外的状态反馈机制时，界面应该明确使用“最后指令”这样的名称。
这也是展示设计的一部分：字段命名必须体现数据能证明什么。 把最后一次 ON 指令直接描述为“设备当前通电”，就会让界面承诺超过系统实际观测能力的结果。
心跳回答的是另一个问题
心跳用于报告客户端最近是否与服务端保持联系。服务端可以根据最近上报时间与设定的超时窗口，推断在线状态。
在线状态和硬件状态不是同一个字段。把它们混在一起，会让界面看起来信息很多，却无法准确回答真正的问题。
边界清楚，界面才可信
一个可靠的跨端状态页面，至少要区分：
- 最近一次指令是什么。
- 指令在什么时候成功写入。
- 客户端最近一次上报心跳是什么时候。
- 系统是否收到物理触点的反馈。
当前版本没有第四项数据时，就不应该假装拥有它。清楚展示能力边界，比制造一个看似完整的开关更重要。