我先后接触过 PLC、服务器、虚拟化平台、摄像头和 MQTT 数据源。每种设备的接入方式不同，但反复出现的麻烦并不是协议本身，而是设备身份。

旧模块里曾经存在多套标识：配置编号、设备注册返回值、IP、设备名称，以及一份 NumberAndDevid 映射。它们在单个 APP 内都说得通，一旦数据进入告警、拓扑、时序库和上层平台，就会出现“同一台设备到底是哪一个”的问题。

哪些字段不能承担身份

设备名称会被人修改，也可能重复。

IP 地址会因网络调整变化，有些设备甚至没有稳定 IP。

数组下标或本地编号只在当前配置中有效，无法跨服务使用。

注册接口返回的 ID依赖在线平台，对边缘离线运行并不友好。

最终我更倾向于把 GUID 放进配置和数据模型，作为跨模块不变的身份。名称和 IP 仍然有用，但它们变成属性，不再承担主键职责。

这项改造并不是全局替换字段名。连接池原来可能按 IP 建索引，告警表可能保存旧设备 ID，历史时序数据无法重写，平台 Topic 也可能已经被外部系统消费。因此迁移需要兼容期：

读取：优先 GUID，缺失时兼容旧映射
写入：新数据只写 GUID
转发：保留旧字段，但明确废弃计划
观测：记录仍在使用旧标识的模块

2026 年初，我又集中删除了多种 PLC 运维 APP 中重复的设备注册逻辑，将客户端映射、属性上传和设备实例逐步改为使用配置中的 GUID。代码少了一部分，系统对平台在线状态的依赖也少了一部分。

协议接入常被描述成“支持了某某型号”。但从长期维护看，更重要的成果是让新设备进入系统后，能够沿同一个身份贯穿采集、存储、告警和转发。