ThinkLink MQTT 集成指南：选择原始报文还是业务遥测，再验证转发

先把数据契约交给接口双方

“支持 MQTT”并不表示两个系统直接连接就能理解彼此。接口双方还需要约定设备身份、主题规则、数据格式、单位、时间语义和异常处理。建议先拿一条已核对的消息作为样本，让接收方说明它需要哪些字段。

如果接收方本身负责设备协议解析，可以选择相应的原始业务报文；如果接收方只做业务分析，使用物模型处理后的遥测通常能减少重复解码。两种方式可以满足不同目的，但不能把数据源选错造成的字段缺失归咎于网络。

AS 与 ThinkLink 消息各自适合什么

平台文档将 AS 与 ThinkLink 列为不同的内部 Broker 类型。前者可提供解密后的上行报文，后者可提供物模型处理后的遥测。订阅 Topic 应与所选消息层和实际组织匹配，不能照抄其他环境的组织路径。

按连接、订阅和转换的顺序配置

当前第三方 MQTT 转发使用 Broker 与转发器。先建立来源连接和第三方目标连接，检查目标 Broker 的运行状态，再开启转发规则并配置订阅主题。第三方连接所需的地址、凭据和证书以对方要求为准。

第一轮建议不加转换脚本，先验证原消息能够到达测试主题。直通确认后，再加入字段重命名、内容筛选或主题转换。每加一层处理，都保留输入样本与期望输出，便于判断消息是没有收到、被规则丢弃，还是被转换成了不同格式。

已有 ChirpStack 或 TTN，不必先迁移无线网络

官方接入桥文档描述了 ChirpStack v4、TTN v3 与 ThinkLink 之间的双向 MQTT 路径。上行先在转发层归一成平台 AS 格式，再由物模型处理；下行则走外部网络服务器的相应接口。平台侧仍需建立适用的设备档案和绑定模型。

这种集成方式适合希望保留现有网络服务、同时使用 ThinkLink 数据能力的项目。验收时要分别验证上下行：能收到一条上行不代表下行队列、目标设备和接收窗口已经工作，也不代表全部历史数据已经同步。

明确断线与重复消息的处理责任

不要因为连接会自动恢复，就推断离线期间的每条业务消息都会自动补发。当前转发器文档说明了订阅恢复行为，也明确没有新增离线消息缓冲与补发保证。若业务需要补偿，应设计可验证的历史查询、持久化或业务重试流程。

接收方还应评估重复消息处理、时间乱序和设备身份映射。可以选择少量测试消息，记录来源时间、目标主题和接收结果，然后模拟连接中断与恢复。最终交付的是可解释的业务结果，而不仅是一张显示连接正常的截图。

1. 在来源侧确认一条真实消息。
2. 核对订阅主题及规则启用状态。
3. 在目标系统核对设备、字段、单位和时间。
4. 验证断线恢复，并记录是否需要额外补偿。