版本标准状态协议级别适合场景新项目建议
MQTT 3.1历史参考3老旧设备、历史 Broker、需要兼容早期 IBM 生态仅在遗留系统要求时使用
MQTT 3.1.1OASIS / ISO 标准4大多数 IoT 设备、工业网关、轻量遥测、最广泛兼容仍可作为兼容性基线
MQTT 5.0OASIS 标准5现代 Broker、云平台、多租户、可观测性、复杂会话与消息控制新系统优先选择
MQTT-SN 1.2相关规范独立协议传感器网络、非 TCP/IP 链路、极低功耗设备只在网络模型需要时采用
MQTT 3.1：历史版本，主要价值是兼容旧系统
MQTT 3.1 是 OASIS 标准化之前的重要基础版本，很多早期 Broker、客户端库和嵌入式设备都围绕它实现。它已经具备 MQTT 的核心模型：Client 与 Broker、CONNECT、PUBLISH、SUBSCRIBE、QoS 0/1/2、Retained Message、Will Message、Keep Alive 和 Topic Filter。
它的问题不在于不能工作，而在于规范表达、互操作细节和错误反馈能力不如后续版本清晰。对现代系统来说，MQTT 3.1 最大的意义是解释历史行为：为什么某些旧设备仍然发送不同的协议名，为什么 Broker 需要兼容旧连接报文，以及为什么某些 SDK 的默认版本不是 3.1.1 或 5.0。
如果你正在做新产品，不应主动选择 MQTT 3.1。只有在设备固件不可升级、现场网关只能说 3.1、或者 Broker 必须兼容早期客户端时，才应该为它保留兼容路径。
实现和排障重点
- 确认 Broker 是否显式开启 MQTT 3.1 兼容。
- 检查 CONNECT 报文中的协议名和协议级别。
- 不要把 MQTT 3.1 的连接失败简单归因于网络问题，很多时候是协议版本协商失败。
MQTT 3.1.1：事实上的兼容性基线
MQTT 3.1.1 是第一个广泛标准化和长期稳定使用的 MQTT 主线版本，也是大量 IoT 设备、网关、开源 Broker 和云平台的共同语言。它保留了 MQTT 的轻量发布订阅模型，同时清理了协议名、连接行为、UTF-8 字符串、WebSocket 传输和一致性要求等细节。
这个版本的最大优点是兼容性。低成本蜂窝模组、边缘网关、PLC 周边设备、旧版移动 SDK、浏览器 MQTT over WebSocket 客户端，通常都能找到稳定的 3.1.1 支持。对只需要基本遥测、命令下发、Retained Message、Last Will 和 QoS 的系统来说，3.1.1 仍然足够。
它的限制也很明显：错误反馈粗糙，很多失败只能用少量返回码表达；没有标准化属性机制，不能在消息中携带用户属性、内容类型、响应主题等元数据；会话过期、消息过期、流控和服务端能力声明都不如 MQTT 5.0 精细。
适合继续使用 3.1.1 的情况
- 设备端 SDK 或模组不支持 MQTT 5.0。
- 消息模型简单，只需要 publish、subscribe、QoS、retain 和 will。
- 你的第一优先级是最大化客户端和 Broker 兼容性。
- 现场设备升级成本高，协议升级收益小于验证成本。
MQTT 5.0：现代 MQTT 系统的首选版本
MQTT 5.0 是当前主线 MQTT 的现代标准。它没有推翻 3.1.1 的发布订阅模型，而是在连接、发布、订阅、确认、断开和错误处理上增加了属性与原因码，让 MQTT 从“能传消息”升级为“能解释消息和连接状态”。
MQTT 5.0 最重要的变化是 Properties 和 Reason Codes。属性让客户端和 Broker 能表达会话过期、消息过期、最大报文大小、接收窗口、Topic Alias、响应主题、相关数据、用户属性、Payload Format Indicator 和 Content Type。原因码让 CONNACK、PUBACK、SUBACK、UNSUBACK、DISCONNECT 等报文能返回更具体的失败原因。
这对真实生产环境很关键。运维人员可以知道连接是认证失败、权限拒绝、协议错误、超过报文大小，还是服务端主动迁移。应用开发者可以用 Response Topic 和 Correlation Data 构建请求响应模式，用 Message Expiry 避免过期命令晚到，用 User Properties 携带业务元数据，用 Receive Maximum 做流控。
MQTT 5.0 关键能力
- Reason Codes：更精确地解释连接、发布、订阅和断开失败。
- Properties：标准化消息与会话元数据。
- Session Expiry Interval：比 3.1.1 的 clean session 更细的会话生命周期控制。
- Message Expiry Interval：避免命令或状态消息在过期后仍被投递。
- Topic Alias：减少重复 Topic 带来的网络开销。
- Receive Maximum 和 Maximum Packet Size：改善背压、流控和资源保护。
- Response Topic 与 Correlation Data：支持标准化请求响应模式。
- User Properties、Content Type、Payload Format Indicator：让消息更容易被业务系统和网关理解。
- Server Reference 与增强 DISCONNECT：支持服务端重定向、迁移和更清晰的断开语义。
MQTT-SN：面向传感网络的相关协议
MQTT-SN 曾称 MQTT-S，目标不是替代普通 MQTT over TCP，而是把 MQTT 的发布订阅思想扩展到非 TCP/IP 网络和受限传感器环境。典型场景包括 Zigbee、低功耗无线传感网络，以及设备不能长期保持 TCP 连接的链路。
MQTT-SN 会引入网关概念，把传感网络中的短地址、Topic ID 和受限通信模型转换到 MQTT Broker 可以理解的发布订阅世界。它更适合对字节开销、休眠唤醒、链路稳定性非常敏感的设备。
如果你的设备已经能稳定使用 TCP/TLS 或 WebSocket，通常不需要 MQTT-SN。如果你的网络不是 IP 网络，或者设备极度受限，才值得评估 MQTT-SN 与网关架构。
选型判断
- 普通云端 IoT 平台、WebSocket 调试、TCP/TLS 设备接入：选择 MQTT 3.1.1 或 5.0。
- 非 TCP/IP 传感网络、短地址网络、低功耗休眠设备：评估 MQTT-SN。
- 需要把传感网络接入现有 MQTT Broker：重点设计 MQTT-SN Gateway。