企业官网建设流程全解析

• 开发工具
• 物联网
• 后端

作为一款可在浏览器中直接运行的 MQTT 5.0 WebSocket 客户端，MQTTX Web 无需安装即可帮助开发者快速调试 MQTT 服务与应用。浏览器客户端天然会引发一个核心疑问：用户的配置、连接信息和收发消息究竟流向哪里？本文以 MQTTX 官方在仓库中维护的《数据收集声明》文档为骨架，逐条拆解其隐私承诺，并结合 web/src 目录下的真实源码，验证"配置数据本地处理""消息仅与所连 Broker 相关""无云端数据处理""仅用 GTM/GA 采集页面访问指标"这四条声明的实现基础。读完本文，你将理解 MQTTX Web 的数据流向边界，以及数据收集政策在产品中是如何被加载与呈现的。

政策文档的背景与位置

《数据收集声明》（日文版原文为《データ収集の免責事項》）是 MQTTX Web 面向最终用户展示的隐私承诺，全文围绕四个核心要点展开：

• 所有配置数据均在用户本机（浏览器）内本地处理，不会从浏览器发送到外部；
• 任何主题与消息数据仅与用户所连接的 MQTT Broker 相关；
• 项目不进行任何云端操作或数据处理；
• 项目使用 Google Tag Manager（GTM）与 Google Analytics（GA）仅收集页面访问指标，不涉及用户隐私数据。

该文档在仓库中以多语言版本维护，同一目录下存在>import Lowdb from 'lowdb' import LocalStorage from 'lowdb/adapters/LocalStorage' class DB { private db: Lowdb.LowdbSync<Schema> public constructor() { const adapter = new LocalStorage('db') this.db = Lowdb(adapter) ... } }

该 Schema 覆盖了窗口尺寸、语言、主题、连接列表（connections）、推荐连接（suggestConnections）、历史负载（payloadsHistory）、历史头信息（headersHistory）等数据，均以localStorage的db键为存储载体。由此可以确认：

• 连接配置（host、port、用户名、密码、MQTT 版本、订阅列表等）通过 web/src/utils/api/connection.ts 的createConnection、updateConnection等函数写入本地数据库；
• 界面设置（当前语言、主题、自动重连、自动滚动、多主题等）通过 web/src/utils/api/setting.ts 的loadSettings/setSettings读写settings字段，而 store 层 web/src/store/modules/app.ts 的每次状态变更（如TOGGLE_LANG、TOGGLE_THEME）都会同步调用setSettings持久化；
• 用户甚至可以通过getAllData()一次性导出全部本地数据、通过importAllData(data)将备份重新写回localStorage，从侧面印证了"数据驻留本地、可由用户自主掌控"的设计。

也就是说，声明第一条描述的"本地处理、不出浏览器"，对应的正是这套以localStorage为后端、无任何服务端参与的状态管理链路。

主题与消息数据为什么"仅与所连 Broker 相关"

声明第二条指出：主题（Topic）和消息（Message）数据仅与用户连接的 MQTT Broker 相关。要理解这句话，需要先看清 MQTTX Web 的网络模型：它是一个纯粹的浏览器直连 Broker的 WebSocket 客户端，消息链路中不存在任何中转服务器。

在 web/src/utils/mqttUtils.ts 中，连接的建立由mqtt.js完成：

const url = getUrl(record) const curConnectClient: MqttClient = mqtt.connect(url, optionsTempWorkAround)

其中getUrl根据用户填写的协议、主机、端口与路径拼接出形如wss://broker.emqx.io:8084/mqtt的 WebSocket 地址（getUrl 实现）。从默认值来看，在线部署环境下默认使用wss协议、端口8084，默认 host 为公共 Brokerbroker.emqx.io（getDefaultRecord）。

由此可以得出明确的技术结论：

1. 消息的收发路径是"浏览器 ⇄ 用户指定 Broker"的点对点链路，MQTTX Web 本身只是消息的载体与可视化工具；
2. 任何主题下的消息内容，其所有权与存储责任都在用户所连接的 Broker 一侧，MQTTX Web 不会在本地持久化一份"服务端副本"，更不会把消息转发给第三方；
3. 用户填写的 Broker 地址完全由用户决定，这也意味着消息数据的边界取决于用户自己选择的服务器。

这一点与声明第一条共同构成了政策的核心：MQTTX Web 是"本地客户端 + 直连 Broker"的架构，项目自身不承担消息数据的中转或汇聚角色。

"不进行任何云端操作或数据处理"的架构依据

声明第三条：项目不进行任何云端操作或数据处理。从仓库结构可以交叉验证：

• web 是一个纯前端工程（web/package.json 中name为mqttx-web），其构建产物为可直接部署的静态站点；
• 前端的数据读写全部落在localStorage（见上文 web/src/database/index.ts），没有任何指向自有后端的业务 API；
• 与外部系统的交互仅有两类：一是用户主动发起的 MQTT 连接（直连 Broker），二是下文将分析的页面统计埋点（GTM/GA）。前者是 MQTT 客户端工具的本职工作，后者仅采集匿名访问指标。

因此，"无云端操作"意味着 MQTTX Web 不存在项目自营的数据处理服务：它既不会替你缓存消息，也不会分析你的连接内容，更不会把配置数据同步到某个账号体系——登录按钮仅用于跳转到 EMQX 平台服务，与本工具的数据处理无耦合。

GTM 与 GA：只采集页面访问指标

声明第四条承认了项目对统计埋点的使用：通过 Google Tag Manager（GTM）与 Google Analytics（GA）收集页面访问指标，但不涉及用户隐私数据。这是整份政策中唯一"出浏览器"的数据，边界清晰。

对应实现位于 web/src/main.ts：

Vue.use(VueGtm, { id: 'GTM-KHSFXHT', enabled: process.env.VUE_APP_IS_ONLINE_ENV === 'true', debug: false, } as VueGtmUseOptions)

需要特别注意的是其中的enabled条件：只有当VUE_APP_IS_ONLINE_ENV环境变量为true（即在线生产部署）时，GTM 埋点才会被激活；在本地开发或离线构建场景下，埋点默认不启用。GTM 容器 ID 为GTM-KHSFXHT，页面内后续的统计行为由该容器统一管理。

与之配套的是 web/src/utils/gaCustomLinks.ts，它为"关于/帮助"页面中的外链（官网、文档、论坛、EMQX Cloud 等）统一拼接utm_source=mqttx-web&utm_medium=referral&utm_campaign=...追踪参数，用于识别这些页面的访问来源。这与声明中"仅收集页面访问指标"的描述一致：采集对象是页面浏览量、外链点击等匿名行为指标，而非用户输入的 MQTT 配置或消息内容。

政策在产品中的呈现方式：关于页面的数据收集声明弹窗

数据收集政策并不只是一份孤立的文档，它在产品中拥有完整的呈现链路，由三个部分协作完成：

1. 入口：在"关于"页面顶部的快捷操作区，存在一个"数据收集政策"链接，点击后打开声明弹窗（见 web/src/views/about/index.vue）；
2. 渲染组件：DataCollectionPolicy.vue 负责加载并渲染 Markdown 内容，弹窗宽度为 540px，且隐藏了取消按钮，仅保留确认关闭；
3. 按语言动态加载：组件监听当前语言变化，按data-collection-${lang}.md的命名规则动态引入对应语言的声明文件：

private async loadAndRenderMarkdown() { const md = markdownit() try { const markdownFile = require(`@/assets/doc/policy/data-collection-${this.getterLang}.md`) this.renderedContent = md.render(markdownFile.default) } catch (error) { console.error('Error loading the markdown file:', error) } }

这意味着：声明正文与界面语言实时联动——切换语言后立即重新渲染对应语言的免责声明；若某一语言的文件缺失，则捕获异常并输出错误日志，不会影响页面其他功能。这种"文档即配置、随语言动态加载"的实现方式，也让后续新增语言只需在 policy 目录 增加同名 Markdown 文件即可。

小结：四项声明对应的实现边界

总结而言，MQTTX Web 的数据收集政策与其"浏览器本地客户端 + WebSocket 直连 Broker"的架构完全吻合：业务数据（配置、消息）始终留在本地与用户自己的 Broker 之间，项目仅通过 GTM/GA 获取最基础的页面访问统计，且这一埋点还受部署环境开关的约束。对于关心数据流向的 MQTT 开发者而言，这份声明与上述源码共同构成了可验证的隐私边界——你可以在 policy 目录 查看中英日三语原文，并通过 DataCollectionPolicy.vue 追踪其在界面中的呈现方式。

• 开发工具
• 物联网
• 后端