ThinkLink MQTT 重连后怎样验收：订阅确认、漏数与业务去重

先画出来源与目标

列出 Source Broker、订阅 Topic、转换脚本、Target Broker 和最终业务消费者。来源选 AS 时关注原始上行，选择 ThinkLink 时关注平台处理后的消息，不要拿不同层的数据数量直接比较。记录目标主题和需要的字段，明确谁负责业务落库。测试先限定一台测试设备或专用主题，避免广泛订阅后把无关消息算进结果。每个样本应有可追踪的业务标识；不要把所有设备同一秒产生的消息都视为一条，也不要只凭消息总数相同就认定没有丢失或重复。

连接与订阅要分别确认

Broker 显示 RUNNING 只能说明连接状态，不证明某条规则已经订阅成功或目标正在消费。当前文档区分订阅需求登记和 SUBACK 确认；来源离线时登记的订阅需要等待连接恢复。核对规则启用、实际主题和订阅结果，再用一条已知消息验证。目标连接正常也不证明转换脚本返回了消息，脚本可能过滤了该报文。排查时按授权范围用最小测试样本检查转换前后内容，不要为临时调试把整个组织的敏感属性转发到不受控 Broker。

提前说明离线期间的承诺

文档明确当前目标不可用时不新增消息缓冲或离线补发保证，因此恢复后收到新消息不代表中断期间已经补齐。项目需要连续历史时，应另行设计可回查来源、补偿任务及去重方式，并验证时间范围与字段对应。固定 client_id 也不单独保证持久会话或业务可靠性；同一 Broker 上非预期重复 ID 还可能导致连接互相替换。修改客户端 ID 会重新连接，安排测试窗口并记录变化。不要把“自动重连”写成“数据永不丢失”，这两者的验收范围不同。

用三个中断场景做验收

先建立正常样本基线，再分别测试来源断线、目标断线和消费者停止处理。每次恢复后核对连接、订阅、目标消息及业务记录，记录缺失与重复标识。即使本地回调避免重复注册，MQTT 重投递或发送端重发仍可能带来重复业务消息。去重键应根据业务定义，结合设备身份、消息标识或可靠序列；不能盲目只按时间戳丢弃同秒数据。测试结果应明确哪些层已恢复，哪些历史区间仍缺失，并把无法观察的层标为未验证而不是默认成功。

1. 建立可追踪的正常样本基线。
2. 分别测试来源、目标与消费者中断。
3. 核对 SUBACK、目标消息与业务记录。
4. 列明缺口、重复和补偿责任。

把恢复手册写给接收方

交付内容包括主题与字段合同、来源和目标责任人、测试标识、重连流程、缺口说明以及消费者的重复处理策略。服务端或共享属性可能只包含白名单子集，消费端要按字段合并；状态通知没有普通遥测结构，不能被仅接受 telemetry_data 的脚本意外丢弃。新增消息类型后重新检查转换条件和目标处理逻辑。恢复验收最终要落到业务消费者，而不是停在 Broker 的连接灯。若需求包括历史补发、事件顺序或可靠审计，应明确列为独立的设计与验收项。