巡检机器人项目里，本体是供应商的事，上位平台往往是企业自己的或者第三方的。两边怎么接，决定了项目是"跑起来了"还是"跑起来了但数据用不起来"。这篇写接口设计的几个关键决策。
一、为什么不能用HTTP轮询
最直觉的做法是机器人定时HTTP请求上报数据。这个方案在Demo里能跑，在现场会出三个问题：

• 实时性差。轮询间隔30秒，告警事件就延迟30秒。
• 连接开销大。每台机器人每分钟建一次TCP连接，几十台机器人同时在线，服务端连接管理压力大。
• 双向通信困难。平台要下发任务指令时，轮询模型不支持服务端主动推送。
  工业场景的正确选择是消息队列模式：机器人与平台之间维持长连接，事件触发即推送，平台指令通过同一连接下发。
  二、MQTT还是OPC UA
  两种主流协议各有适用场景：
  
  实际项目里常见的组合是：机器人侧用MQTT连平台，平台侧再用OPC UA对接DCS。两层各司其职。
  三、心跳与断线重连
  长连接必须有心跳。心跳间隔不能太短（浪费带宽）也不能太长（发现断线太晚）。现场经验值是30秒一次心跳，连续3次心跳无响应判定断线。
  
  重连用指数退避，避免网络恢复瞬间大量机器人同时重连把MQTT Broker打垮。
  四、数据上报模型
  上报的数据分三类，每类一个Topic：
  
  三个设计要点：

1. 时间戳带时区。不要用Unix时间戳整数，用ISO8601带时区。跨时区部署和日志排错时这个细节救命。
2. 告警级别必填。level字段是平台做告警路由的依据，没有级别平台就不知道推给谁。
3. 图片只传URL不传二进制。图片对象存储，消息里只放链接。消息体保持轻量。
   五、断点续传
   无线链路一定会断。断了之后数据不能丢。设计原则：

• 本地持久化。断网期间所有事件和巡检数据写入本地SQLite或文件队列，按时间排序。
• 恢复后续传。网络恢复后，按时间戳逐条补发，平台侧按时间戳去重。
• 容量上限。本地缓存按断网2小时估算。超过上限的旧数据滚动删除，但告警事件（level=1）永久保留直到成功上传。
  六、安全
  机器人接入平台走的是厂区无线网络，安全不能省：

1. 设备认证。每台机器人一个证书，MQTT连接时双向TLS认证。
2. 权限隔离。机器人只能发自己的Topic，不能订阅其他机器人的消息。
3. 指令签名。平台下发的任务指令带签名，机器人验签后执行。防止伪造指令让机器人跑到危险区域。
   接口设计这个东西，Demo阶段都能跑，验收阶段才见真章。核心就是三句话：长连接保实时，本地缓存保不丢，权限隔离保安全。有在做机器人平台对接的同行，欢迎在评论区交流你们的Topic设计。