MQTT 的三个角色
- 发布者（Publisher）：采集网关/设备，把数据发到某个主题
- 代理（Broker）：EMQX/Mosquitto，负责消息路由
- 订阅者（Subscriber）：入库服务、看板、报警服务，订阅主题收数据
发布者和订阅者互不知道对方，天然解耦。
主题（Topic）设计是核心
主题用斜杠分层，要能表达“数据归属”，推荐：厂区/产线/设备/点位。
plant1/line1/press01/temp
plant1/line1/press01/status
plant1/line1/press02/temp通配符：+ 匹配单层（plant1/+/+/temp 订阅 plant1 所有设备温度），# 匹配多层（plant1/# 订阅全厂）。
避坑：不要用中文、空格、特殊字符做主题；不要在主题里放变化过快的值；主题层级保持稳定。
三种 QoS 怎么选
- QoS 0（最多一次）：发完不管，可能丢，适合高频、丢一两条无所谓的实时采样
- QoS 1（至少一次）：保证到达、可能重复，工业采集最常用，消费端要能容忍重复
- QoS 2（恰好一次）：严格不丢不重，开销最大，适合指令、计数等关键操作
工业采集数据通常周期性重复，QoS 1 性价比最高；写控制指令用 QoS 2 更稳妥。
遗嘱消息（LWT）判断意外离线
设备连接时可以登记一份“遗嘱”，当设备异常断线（掉线、断电、网络断）时，Broker 自动替它发布遗嘱消息。
- 正常离线：设备主动发一条“我下线了”
- 意外断线：Broker 发布其 LWT，内容如 status=offline
结合“最后消息时间戳超时判定”，可以可靠区分在线、正常停机、意外掉线。
Retained 保留消息
新订阅者一上线就能拿到该主题最后一条保留消息，适合“设备当前状态”这类主题，看板打开即有值，不用等下一次上报。但高频变化的采样值不建议设 retained。
落地清单
- 先定主题规范文档，全员按规范来
- 采集数据 QoS1，控制指令 QoS2
- 设备状态主题设 retained + LWT
- Broker 开账号认证和权限（ACL），主题级授权
- 用 EMQX 做生产 Broker，轻量边缘场景可用 Mosquitto
规范的 MQTT 设计，是设备规模扩大后系统不乱的前提。