MQTT 3.1.1与MQTT 5.0是物联网领域最核心的两个协议版本，MQTT 5.0并非完全替代前者，而是在3.1.1稳定的基础上增加了更强大的功能。MQTT 3.1.1于2014年成为OASIS标准，以其简洁高效著称；而MQTT 5.0于2019年发布，旨在满足日益复杂的物联网应用场景。
总的来说，两者关系如下：
特性 | MQTT 3.1.1 | MQTT 5.0 |
定位 | ||
核心目标 | 在不可靠网络上，以最小带宽实现可靠的消息传输 | 在3.1.1基础上，提供更精细的控制、更好的可观测性和更灵活的扩展性 |
向后兼容性 | N/A | MQTT 5.0 Broker可以接受MQTT 3.1.1客户端的连接 |
会话管理 | 使用Clean Session标志位，只能选择“保持”或“不保持”会话，缺乏灵活性 | 使用Clean Start和Session Expiry Interval，可精确控制会话过期时间，实现优雅的断连重连 |
错误反馈 | ||
功能扩展 | 功能固定，扩展性差 | |
消息负载 | 每发布一条消息都需携带完整的主题（Topic）字符串 | 引入主题别名（Topic Alias），首次发送后可使用整数替代长主题名，节省带宽 |
性能与流控 | 简单的QoS流控，无端到端的流量控制机制 | |
高级特性 | 不支持共享订阅、请求-响应模式等高级模式 | 原生支持共享订阅（Shared Subscription）、请求-响应（Request-Response） 等，功能更丰富 |
MQTT 3.1.1：使用Clean Session标志位，客户端断连后要么立即清除会话，要么永久保留。这种二元选择容易导致资源浪费或消息丢失。
MQTT 3.1.1：使用Clean Session标志位，客户端断连后要么立即清除会话，要么永久保留。这种二元选择容易导致资源浪费或消息丢失。
MQTT 5.0：用Clean Start和Session Expiry Interval取代。Clean Start决定是否在连接
时复用已有会话，而Session Expiry Interval（会话过期间隔）则指定了断连后会话状态保留的秒数。设置Clean Start=1和Session Expiry Interval=0等价于3.1.1的Clean Session=1；Clean Start=0且不设置过期时间则等价于Clean Session=0。这使得移动设备等不稳定网络场景下的断线重连更加高效。
这是最重要的改进之一，极大提升了系统的可观测性。
MQTT 3.1.1：错误反馈非常有限。例如，CONNACK报文只有5个错误码，无法区分“用户名密码错误”和“客户端被禁止”等具体原因。对于发布(PUBLISH)或取消订阅(UNSUBSCRIBE)等操作，客户端甚至无法得知操作是否成功。
MQTT 5.0：全面引入了原因码，几乎所有应答报文（CONNACK、PUBACK、DISCONNECT等）都可携带，清晰区分成功(值<0x80)和失败(值>=0x80)。服务端还能主动发送DISCONNECT报文并附带原因码，告知客户端被踢出的原因（如“报文过大”），便于客户端采取智能重连策略。此外，还可附加一个人类可读的原因字符串（Reason String） 用于调试。
主题别名 (Topic Alias)：这是专为窄带物联网设计的特性。首次发布时，客户端将主题字符串（如/building/floor3/room10/sensor/temperature）映射为一个整数（如1）。后续发布同一主题的消息时，只需发送这个整数别名，Broker会自动转换，能大幅减少网络流量。
用户属性 (User Properties)：允许在报文中添加自定义的键值对（Key-Value），为应用层提供了灵活的扩展点。可用于传递设备类型、数据格式、路由信息等元数据，而无需修改消息体。
流量控制 (Flow Control)：MQTT 5.0允许客户端和服务端在连接时协商接收最大值（Receive Maximum），即允许对方同时发送的未确认消息的最大数量，实现了更精细的端到端流控。
共享订阅 (Shared Subscription)：这是MQTT 5.0引入的核心高级特性。它允许一组后端服务（消费者）订阅同一个主题，消息只会被该组内的一个消费者处理，实现了天然的负载均衡，是构建高可用、可扩展物联网后端服务的关键。
请求/响应模式：通过在PUBLISH报文中指定Response Topic和Correlation Data属性，实现了无状态的请求-响应通信，方便物联网设备向云端发起指令并接收反馈，简化了异步通信的开发。
增强认证：新增AUTH报文，支持质询/响应（Challenge/Response）式的双向认证，如SCRAM，为对安全性要求极高的场景提供了更强的保障。
订阅与发布选项：MQTT 5.0提供了更丰富的订阅选项，如No Local（不接收自己发布的消息）、Retain As Published（保留原始保留标志）和Retain Handling（控制保留消息的发送时机）。此外，还引入了订阅标识符（Subscription Identifier），帮助客户端区分消息是由哪个订阅（尤其是通配符订阅）触发的，简化了回调处理。
向后兼容性：MQTT 5.0在协议层面是向后兼容的。MQTT 5.0 Broker可以接受MQTT 3.1.1客户端的连接，但这些旧版客户端无法享受5.0的新特性。
迁移建议：迁移到MQTT 5.0时，需升级服务端（Broker）和客户端SDK。建议先在非生产环境进行充分测试，验证新特性的行为，特别是默认行为与3.1.1是否一致。
(1) 版本选择建议
选择哪个版本，最终取决于你的具体业务场景：
场景 | 推荐版本 | 核心理由 |
传统IoT应用 | MQTT 3.1.1 | 生态成熟，兼容性好，对于大多数场景已足够。 |
后端服务处理海量设备 | MQTT 5.0 | 共享订阅是构建可扩展、高可用后端服务的刚需。 |
窄带/低功耗网络 (NB-IoT) | MQTT 5.0 | 主题别名能有效减少传输数据量，降低功耗和成本。 |
云平台基础服务 | 同时支持 | 主流云厂商通常同时支持两个版本，以满足不同设备的需求。 |
需要精细化错误处理 | MQTT 5.0 | 原因码极大地简化了问题排查和自动化运维。 |
需要端到端流量控制 | MQTT 5.0 | 原生的流量控制机制能有效防止Broker或客户端过载。 |
需要实现请求-响应模式 | MQTT 5.0 | 内置的请求-响应特性简化了异步通信的开发。 |
注意：虽然MQTT 5.0功能强大，但部分Broker对其支持可能不完全。例如，一些平台目前尚未支持AUTH报文、遗嘱延迟等高级特性。在选型时，建议查阅所用Broker的官方文档，确认其对MQTT 5.0特性的支持程度。
