定义
MQTT（Message Queuing Telemetry Transport）是轻量级物联网消息协议，基于发布/订阅模式，适合低带宽、高延迟网络。平台原生支持 MQTT 3.1.1 与 MQTT 5.0，支持 QoS、Retained Message、Last Will 等特性。
核心特点
- 轻量：协议开销小，适合 NB-IoT、2G 等窄带场景
- 发布/订阅：基于 Topic 的消息路由
- QoS：支持 0/1/2 三级消息质量保证
在设备接入中的应用
MQTT 是设备管理平台 Device Access 接入层的核心协议。设备通过 Topic 上报 Telemetry 遥测数据、接收 Downstream Command 下行指令、订阅 OTA 通知等。平台通常约定 Topic 规范（如 /product/{productKey}/device/{deviceId}/property/post），支持 QoS 保障关键消息可靠送达，Last Will 用于检测设备异常断开。
安全与扩展
生产环境需启用 TLS 加密，支持 mTLS 双向认证或 X.509 Certificate 证书认证。MQTT 5.0 新增共享订阅、请求/响应、用户属性等能力，适合大规模、多租户场景。与 LwM2M、CoAP 等协议并存，满足不同设备类型的接入需求。
主题订阅在接入层承担什么
MQTT 在设备接入里是一条基于主题的发布订阅通道。设备与代理建立会话后，向约定主题发布测点或事件，并订阅自己的下行主题以接收命令、属性期望和升级通知。代理按主题把消息转给当前订阅者，不负责解释测点的业务含义。主题因此要有稳定的层级，把产品、设备、方向和数据类型分开，避免把全部内容堆进一个公共主题再靠正文区分。服务质量等级决定代理和设备要不要确认、要不要保证不重复：等级越高，握手越多，窄带越不该滥用在高频采样上。保留消息会让后上线的订阅者立刻拿到最后一条，适合放“当前期望”，不适合放每一条历史告警。遗嘱在异常断开时由代理代发，用来表达“这台设备没有正常告别”，不能当成业务告警的唯一来源。会话是否在断开后保留订阅，决定设备重连时要不要重新订阅。物模型属性与主题的对应关系应写进接入约定，而不是散落在各端代码里。
什么样的消息适合走这条通道
适合的是小而频繁的状态、偶尔的命令和短的进度通知。大文件、固件包体和长日志不应塞进单条消息，它们应走专门的下载或分片，这条通道只传地址和进度。关键命令至少要能确认到达，并在应用层带上命令标识以便去重；只求尽快发出、允许丢失的采样，才用最低等级。设备身份要在连接时完成，不能只靠主题字符串里的设备名自称。共享订阅适合平台侧多个处理实例分摊上行，不适合让多台设备共用一个会丢消息的订阅组去收命令。遗嘱、保留和清理会话这三个开关要按产品写明默认值。和设备影子一起用时，影子中的期望下发和设备上报的实际值应走不同主题，避免处理程序把期望写回成实际值。
服务质量与会话开关用反
把控制命令放在最低服务质量上，网络抖动时命令丢失，平台却显示已发送。把每秒一次的采样放在最高等级，确认报文把窄带占满，采样本身反而堆积。客户端标识重复，后上线的设备把前一台挤下线，两边都表现为不稳定。清理会话设成每次断开就丢订阅，设备若没在重连后重新订阅，下行会一直发到没有接收者的主题。保留消息里留了旧的重启命令，新设备一订阅就被执行。遗嘱主题和正常告警主题相同，代理代发的断线被业务系统当成传感器故障。主题权限只限制了写、没限制读，任何持有连接的客户端都能订阅他人上行。重连风暴时所有设备同时建立会话，代理过载，又触发更多重连。用主题层级代替授权，把设备名放进主题就认为只有它能发布，伪造主题即可冒充。