保留消息解决冷启动
订阅方默认只能收到订阅之后发布的消息，设备刚上电或平台刚启动时看不到当前状态。保留消息为此设计：发布时置保留标志，代理为该主题保存这条消息，之后任何订阅该主题的客户端都会立即收到它；要清除，向同一主题发布一条空载荷的保留消息即可。
基本信息
| 存储位置 | 代理侧按主题保存最后一条，与客户端会话无关 |
|---|---|
| 生效时机 | 新订阅建立时立即下发，不等待下一次发布 |
| 清除方式 | 向同一主题发布空载荷并置保留标志 |
| 常见搭配 | 状态主题配保留消息，遥测主题只用普通消息 |
| 资源影响 | 保留消息持续占用服务端内存或存储，需要设上限与过期策略 |
适用与不适用
| 数据类别 | 是否适合保留 | 原因 |
|---|---|---|
| 设备在线状态 | 适合 | 订阅方立刻知道当前状态，无需等待下一次上报 |
| 配置与固件版本 | 适合 | 变化频率低，冷启动即可读取当前值 |
| 高频遥测 | 不适合 | 每条都保留等于把最新值写满服务端，且价值有限 |
| 事件与告警 | 不适合 | 事件有先后顺序，保留最后一条会造成语义误解 |
| 历史数据 | 不适合 | 代理只保存最后一条，无法替代时序存储 |
典型使用场景
- 监控大屏冷启动：订阅后立刻显示各设备当前状态，而不是空白等下一次上报
- 设备状态同步：平台重启后马上恢复已知的设备在线状态
- 临时诊断：用保留消息记录设备最近一次自检结果，便于随时查看
- 配置下发确认：保留最近一次生效的配置版本，便于比对
保留消息的载荷最好带时间戳或序号，订阅方据此判断这条状态是刚刚更新还是几天前的残留，避免把过期状态当成实时状态。
用通配符订阅时，新客户端会在建立订阅瞬间收到大量保留消息，设备规模大时可能造成启动拥塞，需要评估订阅范围与服务端下发策略。