消息还没到期，会话为何能先结束它：MQTT 5的两种期限关系

MQTT 5里，一条消息还有自己的有效期，为什么仍可能随着会话一起到期？HiveMQ的专题文章把Session Expiry Interval与Message Expiry Interval分开说明，又在两者关系处给出一项明确提醒：客户端会话过期时，为这个客户端排队的消息也同时过期，不论它们各自的消息期限如何。两种期限并非彼此独立的保留保证。

会话期限首先针对broker保存的客户端会话信息。它讨论网络连接结束之后，这份会话数据继续保留多久。连接结束与会话数据消失，在该说明中不是必然同一时刻；会话可以在客户端暂时不在线时继续存在。这里讨论的是服务器上的状态，而不是一条报文从发送到抵达经过多长时间。

消息期限的对象更小。原页说，每条PUBLISH消息可以有各自的Message Expiry Interval，决定broker为匹配主题但暂时离线的订阅者保留它多久。不同消息因此不必共享同一相关性窗口。一条短时资讯与另一条需要较长时间仍可取得的信息，在文档中可以用不同的消息期限表达。

文章用联网汽车的交通更新和固件更新作文字例子，说明内容相关时间可能差别很大：交通状况较快失去意义，另一类更新的信息则可能需要保留更久。本篇只借此说明消息内容为什么会有不同期限，没有为车辆选择期限、执行更新，或沿用例子里的具体时长作为任何系统要求。

保留消息也出现在同一说明中。对于在主题上保留的消息，消息期限同样决定它在多长时间内仍可发给新订阅者。因此，Message Expiry并非只与一段客户端离线排队有关；原文同时把它联系到主题上的保留内容。但这不把保留消息扩写成该主题曾经发布过的完整历史。

最容易遗漏的是两层期限相遇时的结果。即使某条排队消息单独看来尚有剩余时间，客户端会话先过期，它也随该会话的排队内容一起到期。单条期限没有让消息脱离所属会话无限保留。反过来，一份尚存在的会话，也不会令其中具有较短消息期限的内容永远有效。这里比较的是保存对象及期限关系，不是消息送达后的业务执行结果。

HiveMQ把这两项联系到broker资源管理和避免重新连接时接收过时内容。本文采用其MQTT 5连续解释与邻接，网页首次日期未确认；不采用连接标志、数值设置或服务端管理步骤。保留会话数据、单条消息及主题保留消息这几个对象，才能准确理解“消息未到期”究竟还受哪一层条件限制。