无人超市系统和普通后台管理系统最大的区别，是页面背后连接了真实设备。摄像头、自动称重货柜、环境检测设备都在持续产生状态和数据，运营人员关心的不是某一条记录是否保存成功，而是现场设备是否正常、是否有异常、是否需要处理。
这篇文章整理我对无人超市项目中 IoT 设备监控、状态展示和异常告警的一些理解。
业务场景
无人超市场景里，设备类型比较多，关注点也不同：
| 设备类型 | 页面关注点 |
|---|---|
| 摄像头 | 在线状态、画面可用性、设备位置、异常记录 |
| 自动称重货柜 | 重量变化、货柜状态、数据回传、异常开关门 |
| 环境检测设备 | 温度、湿度、烟雾或其他环境指标 |
| 网关或控制设备 | 通信状态、最后心跳、任务执行结果 |
如果每一种设备都单独做一套页面，后续维护成本会很高。更稳妥的做法是抽象出统一的设备信息、在线状态、最近数据和告警记录，再针对不同设备补充特有字段。
统一设备状态
设备状态不能只分成在线和离线。实际项目里，运营人员更需要知道设备现在是否可用、数据是否可信、异常是否已经处理。
一个更实用的状态模型可以包括：
- 正常：设备在线，数据按时回传。
- 离线：超过心跳时间没有回传。
- 异常：设备在线，但指标或运行状态异常。
- 告警中：已经触发告警，需要人工确认。
- 维护中：设备暂时不参与业务判断。
前端展示这些状态时，要让列表可以快速扫描，详情页可以看到最近心跳、最近数据和告警原因。
摄像头监控的页面重点
摄像头不只是一个设备名称。页面通常需要展示设备位置、在线状态、最近更新时间和异常记录。如果项目支持画面预览，还要考虑画面加载失败、设备离线、权限不足等场景。
对运营人员来说，最重要的是快速判断：
- 哪些摄像头离线。
- 哪些摄像头最近没有回传。
- 异常发生在哪个区域。
- 是否需要联系现场处理。
所以摄像头管理页面要重视状态筛选和异常入口，而不是只做设备信息 CRUD。
自动称重货柜的监控逻辑
称重货柜的关键是数据变化。重量变化可能意味着商品被取走、补货、误触发或设备异常。软件侧需要根据回传数据和业务阈值判断是否提示异常。
常见关注点包括：
- 重量是否持续回传。
- 变化是否超过正常范围。
- 货柜状态是否和业务操作一致。
- 异常开门、异常重量波动是否需要告警。
这类逻辑不能全放在前端判断。前端更适合展示结果、趋势和操作入口，后端更适合做数据聚合、阈值判断和告警生成。
环境检测设备的告警
环境检测设备关注的是指标是否越界。例如温度、湿度或烟雾指标异常时，系统需要及时提醒运营人员。
页面展示时可以分层：
- 列表展示当前状态和最新指标。
- 详情页展示历史变化和最近告警。
- 告警记录展示发生时间、设备、指标、级别和处理状态。
这样既能快速发现问题，也能追踪问题是否已经处理。
前后端和硬件联调边界
多设备 IoT 项目里，联调边界要清楚：
- 硬件或网关负责真实采集和上报。
- 后端负责接收数据、计算状态、生成告警、提供查询接口。
- 前端负责展示设备状态、异常原因和操作入口。
如果边界不清楚，前端很容易被迫猜设备是否异常；如果后端没有沉淀状态规则，页面也很难保持一致。
收获
无人超市项目让我更理解 IoT 设备监控的核心：不是把不同设备硬塞进一个列表，而是把设备状态、业务指标、告警原因和处理入口组织成运营人员能理解的页面。
对我来说，这个项目体现的是软硬件联调能力和业务状态抽象能力。前端不只是展示设备数据，还要把复杂的设备运行情况转化成可判断、可处理的信息。