MQTT 重连后订阅还在不在，怎样核对 Clean Start 与会话过期

MQTT 5.0 重连后能否继续旧订阅，要联合看 Clean Start、Session Expiry Interval 和 CONNACK 的 Session Present。Clean Start=0只是请求续用；如果旧会话已经不存在，服务端仍会建立新会话。不能因为客户端参数里写了“持久”，就省掉对实际连接结果的核对。

环境和证据范围

本文计算断开后会话是否仍可能存在，不启动代理，也不测试代理磁盘持久化。示例假设同一ClientID、同一服务端、会话没有被管理员清除，没有集群故障；MQTT 3.1.1 的CleanSession不是MQTT5参数的同名替换。

核对顺序

1. 先记录上一次连接协商的会话过期秒数，以及断开时是否用DISCONNECT修改了该值。过期0表示网络连接结束后会话不保留，不能只看客户端配置文件中的默认值。

2. 列出本次Clean Start与实际离线间隔。如果Clean Start=1，应按新会话处理；如果为0且旧会话尚存，才有续用基础。恰好到截止时刻的样例按已到期处理，现场边界还需看服务端日志。

3. 收到CONNACK后按Session Present决策。为0时重建订阅与初始状态；为1时核对既有订阅和未完成交换。避免无条件重复SUBSCRIBE带来意外的保留值重新分发。

可复算的输入与预期

四个合成场景：过期60秒、离线20秒、Clean Start=0得到“可续用”；过期60秒离线60秒得到“新会话”；离线20秒但Clean Start=1得到“新会话”；过期0也得到“新会话”。脚本输出的是前置条件下的预期，并不伪造CONNACK实测。

会话状态与保留记录也应分开：旧会话到期并不等于相关主题的保留消息一同删除。建立新会话后重新订阅，仍可能收到代理保存的保留值。因此恢复订阅、清理队列与检查初始状态时效，应在记录表中分别留下结论。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 client_id、clean_start、negotiated_expiry_s、offline_s、session_present、subscription_action。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

同一ClientID被另一台设备接管，会让连接行为偏离这张简表；代理重启是否保留会话也取决于实现和配置。实际Session Present与预期不一致时，先检查ClientID、服务端节点、管理员清理和最终协商值，不要反复盲目重订阅。

移交表要保留连接前配置、服务端接受值、断开时间、重连时间和Session Present实值。订阅恢复与看板恢复分开签收，旧订阅在并不代表状态负载就是新鲜的，也不代表设备动作完成。

基础背景可看MQTT 物联网控制协议在展厅的应用速查。旧会话仍在时，积压消息还要单独检查寿命，见断线期间积压的 MQTT 指令，怎样用消息过期限制补发。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§3.1.2.11.2与§3.2.2.1 Session Present

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。