MQTT保留消息与持久会话，为什么不能都叫离线消息队列

一个终端重新上线后收到了消息，并不能单凭这个现象判断服务保存了离线期间的全部记录。在AWS IoT Core的MQTT说明中，保留消息与持久会话是不同机制。前者与主题上保存的最近消息有关，后者则与客户端会话状态及适用消息的排队有关。

保留消息按主题保存，文档说明每个主题只保留一条。新的保留消息会替代该主题已有的保留消息，因此它适合用来理解“最近保留下来的状态”，不能直接解释成这个主题完整的历史流水。主题先后更新多次，也不意味着后来订阅者会据此收到每一次变化。

持久会话则会维护订阅等状态，并在相应条件下为离线客户端保存符合要求的QoS 1消息，等待恢复连接后处理。这里存在会话到期、配额等限制，不能删去条件后概括为离线消息永不丢失。阅读项目记录时，还应确认实际使用的会话设置是否与假设相符。

订阅方式也影响保留消息的接收。AWS文档注明，要在订阅时获得对应保留消息，主题过滤器需要精确匹配该主题；带通配符的订阅不能按这一方式取得保留消息。因而“已经订阅了相关范围”仍不足以证明最初那条保留值一定会到达。

举一个自拟的资料对照场景：面板希望知道设备最后公布的一个状态，与审计希望查看离线期间发生的多次事件，所需证据并不相同。前者可能涉及保留消息，后者需要另外核对实际会话与存储安排。这个例子只用于区分需求，没有连接设备，也没有验证任何系统的消息完整性。

两种机制可以组合使用，却不会因为组合就自动成为无限历史库。本文依据AWS IoT Core官方文档解释概念，不提供生产系统配置或设备控制方案。写运行记录时，明确采用哪种机制、已验证哪种消息以及仍有哪些限制，能避免把一次成功接收误写成全量可靠性证明。