MQTT连接结束时，遗嘱消息为何可能发布、被删除或延后

MQTT资料里的Will Message通常译作遗嘱消息，但它不是客户端在连接断开之后才临时发出的一句告别。2014年10月29日的OASIS MQTT 3.1.1标准，在3.1.2.5节先交代存储条件：设定了Will标志，并且连接请求被接受时，服务器须存储这条消息，将它关联到该网络连接。后面的结束路径，才决定这份已存消息怎样处理。

标准规定，连接随后关闭时应发布Will，但保留了一个明确例外：服务器收到DISCONNECT报文并删除了Will。3.14节将DISCONNECT解释为客户端发给服务器的最终控制报文，表示干净地断开；服务器收到它后，应丢弃当前连接所关联的Will而不发布。这里不能省略“服务器收到”这一条件，不能把一份只记录客户端打算断开的材料，直接说成服务器已按正常结束处理。

并非所有连接都预存有Will。3.1.2.5还明确说明，未设置Will标志时，网络连接结束不得发布Will。因此，仅凭没看到遗嘱消息，不能倒推出连接始终正常；还需要知道该连接原本是否具备对应条件。这个判断停留在协议说明，并没有连接设备核对任何真实报文。

对于会发布Will的情形，原文举例包括服务器检测到I/O或网络失败、客户端未在Keep Alive期间通信、客户端没有先发送DISCONNECT便关闭连接，以及服务器因协议错误关闭连接。多个原因都可能进入所述路径，说明看到Will不等于已经查明设备断电或硬件损坏。消息的协议角色与现实故障的诊断，需要各自的证据。

时间也有一项边界。标准说服务器应及时发布Will，同时允许在服务器关闭或失败时，将发布延至后续重启。这意味着消息出现时刻与服务器经历问题的时刻可能有间隔。将后来看到的消息时间直接当成物理故障发生的精确时间，会超出该机制能说明的范围。标准还规定，Will在发布之后，或者服务器收到DISCONNECT之后，应从存储状态中移除。

对物联网连接资料，预存条件、连接结束原因、正常结束例外和服务器处理时间，组成了比“离线就发消息”更完整的联系。本篇只采用上述历史标准的两节及邻接文字，不把它说成MQTT所有版本与全部服务的相同实现；没有采用标志位数值、设置代码、连接或删除步骤，也不保证任何消息已经送达。把Will解释为带条件的服务器处理，才能避免用一条消息替实际设备状态作未经核验的结论。