MQTT 3.1.1的DUP标记，为什么不能代替业务消息去重

物联网联调日志里，一条PUBLISH报文带着DUP=1，能否直接写成“业务已重复执行”？反过来，DUP=0是否足以证明内容从未出现？OASIS的MQTT 3.1.1标准在DUP一节，明确区分了控制报文与其中承载的应用消息。

这份标准的身份为2014年10月29日的OASIS Standard。第3.3.1.1节说明，DUP为0表示客户端或服务器第一次尝试发送这一PUBLISH报文；为1表示它可能是对先前发送尝试的再投递。接收方看到1，不能假定自己已经见过该报文的较早副本。“发送方再次尝试”没有自动变成“接收方上次已收到”。

同节随后的非规范性说明专门强调，DUP指向控制报文本身，而非其中的应用消息。使用QoS 1时，客户端可能收到DUP为0的PUBLISH，里面却重复了以前收到的应用消息，而且采用不同的Packet Identifier。因此，零值也不是业务内容唯一性的证明。

转发还有一个范围变化。标准要求，服务器向订阅者发送PUBLISH时，不直接沿用收到的DUP值；发出的值独立确定，只依据这次向外发送是否为重传。发布端到服务器与服务器到订阅端，不能因为承载相关内容，就被当成同一份标记记录。第4.3节也将交付协议限定为单个发送者与单个接收者之间的交付，各订阅客户端分别处理。

Packet Identifier同样不是永久业务编号。第2.3.1节说明，在相应确认被处理后，标识符可再次使用，客户端与服务器还会独立分配。一个标识值曾出现过，并不能脱离方向和协议过程认定今天收到的就是同一业务事件。本文只解释标识范围，没有据此判断某台设备的具体消息是否重复。

整理联调记录时，可以分别保留连接及方向、控制报文标记、协议标识，以及已有的业务事件身份。若记录只有DUP，就如实描述这个报文的标记状态；是否重复执行，需要接收、处理与业务结果的对应证据。这里是资料分析，不是新的去重算法或生产配置方案。

本篇采用3.1.1标准第2.3.1、3.3及4.3中关于标识、PUBLISH与交付范围的文字，不据流程图判断具体设备状态，也不将这一版本的结论直接推广为其他版本的全部规则。让DUP保留控制报文层的含义，业务层的未知才能被准确留下。