MQTT 日志里 DUP=1 就是重复业务吗，怎样分开报文与事件编号

DUP=1 表示该 MQTT 控制报文可能是重发，不能直接据此断言某个业务事件已经执行过。Packet Identifier 也是协议交换中的编号，可以在合适时机复用，不能当作永久事件主键。排查时应同时保留连接标识、方向、packet_id、DUP 和应用自己的 event_id，分清“报文重发”与“业务内容再次出现”。

环境和证据范围

限定 QoS 1 的合成日志解释，不实现设备动作去重，也不代替按钮连点验收。MQTT 投递保证有其协议端点范围；代理收到、订阅者收到、适配器处理、设备完成是不同证据。本文没有抓取实际代理的报文。

核对顺序

1. 先固定日志来自发布端到代理，还是代理到订阅端，两段链路的Packet Identifier不应混为一谈。连接断开后重新建立连接，也要保存会话是否续用；单独一个数字无法重建交换过程。

2. 在传输日志中标出DUP，但在业务日志中另列event_id。先寻找同一协议交换的重发证据，再比较相同应用事件是否出现于不同报文；缺少PUBACK等上下文时，标记为“可能重发”，不要武断归并。

3. 使用新连接复用packet_id的反例检查分析工具。报文编号碰巧相同但event_id不同，应保留为不同业务输入；同一event_id即使DUP=0，也值得追查上游是否重新发布。

可复算的输入与预期

夹具有四条记录：连接c1的id7首次发布E1、id7带DUP再次出现E1、id8不带DUP但仍携带E1、连接c2的id7携带E2。离线结果逐条输出“首次/可能报文重发/应用事件再次出现/新连接新事件”。这些标签是取证提示，不能直接触发或阻断设备动作。

确认轨迹还要标注是否完成一轮协议交换。某个编号在完成后重新使用是允许的，分析工具若永久记住所有packet_id会制造假重复。event_id若来自业务负载，也需注明它是消息标识、状态版本还是实际操作标识，三者不能直接互换。

下载与现场记录

下载本题合成输入与预期JSON、离线只读核验脚本和现场空白记录CSV。放在同一目录，用 Python 3 运行 python verify.py，逐项计算或解析后与预期比较，失败会显示差异。

现场字段包括 direction、connection、session_present、packet_id、dup、event_id、ack_evidence。合成样例保持原样，实测另存并填写型号、版本、证据路径，未采集处留空。本地核验不代表真实设备、代理、浏览器或长期稳定性已测。

失败分支与移交

DUP=0不保证业务从未见过，DUP=1也不证明接收端此前成功收到。同一event_id的含义还取决于应用契约，可能是一次事件重发，也可能是错误复用。若只能获得最终按钮状态，证据不足，先补协议出口和业务入口日志。

给开发者的材料应包括两段传输方向、会话信息与原始确认轨迹，并明确event_id的生成方和有效范围。需要验证业务副作用时，应再做独立的场景去重实验，不把这一页的日志分类当作业务恰好一次保证。

基础背景可看MQTT 物联网控制协议在展厅的应用速查。需要把业务回复配回请求时，再核对MQTT 回执对应错请求，怎样核对 Response Topic 与关联字节。更多资料在设备协议库。

需要接入中控时，可对照SoftControl设备联动需求核实适配范围；独立校验方法是否纳入交付需逐项约定。

一级资料

• 官方资料：§3.3.1.1与§4.3.2，DUP字段和QoS1交付范围

核对日期：2026-10-24。规范定义与本文应用约定分开，示例门限及脚本不自动代表产品原生能力。