MQTT 3.1.1 自 2014 年发布以来，已成为物联网通信的主流协议。但随着物联网场景的复杂化——大规模设备接入、云端弹性扩缩容、消息时效性要求提高——3.1.1 的一些局限逐渐显现。MQTT 5.0 在 2019 年正式成为 OASIS 标准，在保持轻量本质的同时，引入了一系列企业级特性。
一、MQTT 3.1.1 vs 5.0 核心对比
| 特性 | MQTT 3.1.1 | MQTT 5.0 |
|---|---|---|
| 共享订阅 | ❌ 不支持 | ✅ $share/<group>/<topic> |
| 消息过期 | ❌ 不支持 | ✅ Message Expiry Interval |
| 会话过期 | ❌ 仅开/关 | ✅ 可配置秒数 |
| 主题别名 | ❌ 不支持 | ✅ 整数代替主题名 |
| 最大报文长度 | ❌ 不支持 | ✅ 连接时协商 |
| 原因码 | ⚠️ 少数几个 | ✅ 丰富的错误码+原因字符串 |
| 服务器重定向 | ❌ 不支持 | ✅ CONNACK/DISCONNECT 携带 |
| 基础发布订阅 | ✅ 支持 | ✅ 兼容 |
二、共享订阅：消费端负载均衡的原生支持
在 MQTT 3.1.1 中，如果多个客户端订阅同一个主题，Broker 会将每条消息复制后发送给所有订阅者（广播模式）。这在需要横向扩展消费能力的场景下存在问题——比如后端有 5 个数据处理实例，每条消息被处理 5 次，造成资源浪费和重复处理。
MQTT 5.0 的共享订阅（Shared Subscription）原生解决了这个问题。订阅者使用特殊主题格式 $share/<group-name>/<topic-filter> 加入共享组，Broker 将消息以负载均衡的方式分发给组内的一个订阅者。
共享订阅的负载均衡策略通常支持轮询（Round Robin）、随机（Random）、最少未确认（Fewest In-flight）等方式，确保消息在多个消费者之间均匀分布。
三、消息过期与会话过期
消息过期（Message Expiry Interval）
在持久会话 + QoS 1/2 场景下，设备长时间离线时 Broker 会缓存大量待发送消息。设备重连后可能收到大量已过时的消息（如几小时前的温度读数），既浪费带宽又可能误导业务。MQTT 5.0 允许发布者在 PUBLISH 报文中设置消息有效时长（秒），Broker 超过有效期后自动丢弃。
会话过期（Session Expiry Interval）
MQTT 3.1.1 的持久会话只有"开"和"关"两种状态。MQTT 5.0 将会话过期独立为可配置参数：设置为 0 断开即清除，设置为 0xFFFFFFFF 永久保存，设置具体数值（如 86400=24小时）则离线超时后清除，避免大量不活跃会话占用内存。
四、其他重要新特性
🏷️ 主题别名（Topic Alias）
用整数（1-65535）代替长主题名，后续消息只传别名，大幅减少报文长度，适合低带宽网络和高频小报文场景。
📏 最大报文长度
客户端和 Broker 连接时协商各自能接受的最大报文长度，超过限制的报文被拒绝并返回错误码，避免超大报文导致内存溢出。
⚠️ 丰富原因码
从 3.1.1 的少数几个码扩展到覆盖未授权、主题无效、配额超限、服务繁忙等场景，支持携带人类可读的错误字符串，便于问题定位。
🔄 服务器重定向
Broker 可在 CONNACK 或 DISCONNECT 报文中携带重定向地址，引导客户端连接其他 Broker 实例，支持负载均衡和滚动升级。
五、双协议兼容与选型建议
MQTT 5.0 完全向后兼容基础发布订阅功能，Broker 可同时支持 3.1.1 和 5.0 客户端。客户端在 CONNECT 报文中声明协议版本，Broker 按对应版本处理。3.1.1 和 5.0 客户端可连接同一 Broker 通过主题互相通信，但 5.0 新特性（如共享订阅）只有 5.0 客户端能使用。
选型建议：资源极度受限的嵌入式设备（8-bit MCU、NB-IoT 终端）使用 3.1.1 即可；有消费端负载均衡、消息时效性、弹性扩缩容需求的中大型系统，建议直接使用 5.0。芯祥联 MQTT SDK 通过编译开关切换 3.1.1/5.0，Client 端提供 v311 和 v50 两版预编译库，接口保持一致。