MQTTX 下载与使用：EMQ 出的 MQTT 客户端，还带命令行版（v1.13.0）

先把话说在前面：如果你手上已经有一个网络调试助手，它多半就支持 MQTT。站内写过的 NetAssist 支持 MQTT Client，SCOMM 也支持。那还有必要再装一个 MQTTX 吗？

有必要，但不是所有时候都有必要。这篇就想把这条界线画清楚。

顺带支持，和专门做

综合型调试助手里的 MQTT 功能，是顺带支持。它的设计目标很明确：让你填个地址、填个主题，点发送、看接收，确认「这条链路是通的」。做到这一步，它完全够用，而且比再装一个软件快。

MQTTX 是专做 MQTT 的工具。EMQ 出品，官网在 mqttx.app，源码在 GitHub 的 emqx/MQTTX，许可证 Apache-2.0，最新版本 v1.13.0 发布于 2026 年 1 月 23 日。

差别在哪里？在你不再是「验证一下」，而是要长期跟一套 MQTT 系统打交道的时候。主题一多，你需要能把它们分门别类地管起来，而不是每次手打一遍；你要观察保留消息的行为，看新订阅者接进来到底拿没拿到最后那条；你要比较不同 QoS 等级下消息的送达表现。这些事在「顺带支持」的界面里做，会很快变成来回切窗口、手抄记录的体力活。

所以分界线可以这么定：

• 只是验证链路通不通 —— 用手头已有的综合工具，别折腾。
• 真要调 MQTT 的行为 —— 换专用的。

界线本身比工具重要。装了专业工具却只用它发一条消息，和用综合工具硬啃主题树管理，是同一类浪费。

容易被忽略的另一半：命令行版

很多人只知道 MQTTX 是个桌面客户端，其实官方的发布资产里同时有两类东西。

桌面版覆盖三个平台：Windows 有安装包和免安装压缩包，64 位和 32 位各一份；macOS 分别提供了给 Intel 和给 Apple Silicon 的两个 dmg；Linux 有 AppImage（x86 和 arm64）和 deb 包。这部分和你预期的差不多。

真正值得单独说的是命令行版本——官方同样发布了 mqttx-cli-win-x64.exe 和 mqttx-cli-win-arm64.exe 这类文件。

CLI 的意义不在于「省得开窗口」，而在于它能进 CI 和脚本。想一下这个场景：你的自动化测试跑到某一步，需要往某个主题发一条消息，然后订阅另一个主题、等设备的响应、拿结果做断言。这件事 GUI 根本做不了——GUI 要人点。有了 CLI，它就是流水线里的一条普通命令，和跑测试、跑构建没什么区别。

同理还有运维侧的小活：定时往某个主题发一条心跳、部署完之后自动订阅几个关键主题确认服务正常。这些都是脚本的活，不是人的活。

具体的子命令、参数怎么写，以官方文档为准——这类信息随版本变化，抄在文章里只会过期误导。你需要先知道的是「有这东西」，剩下的查文档就行。

为什么 MQTT 的排查方向是三条不是一条

用惯 HTTP 的人第一次调 MQTT，最容易卡在模型差别上。

HTTP 是请求响应：你发一个请求，对面给你一个响应，一来一回是配对的。调试方式也就顺理成章——调用一个接口，看它返回什么，状态码和响应体直接告诉你发生了什么。

MQTT 是发布订阅：消息的发送方和接收方互相不认识，中间隔着一个 Broker 中转。发布方把消息发给 Broker，说明发到哪个主题；订阅方向 Broker 说自己关心哪个主题，之后 Broker 有消息就推给它。两边谁也不知道对方是谁、在不在线。

这个差别直接决定了调试方式不同。你不是「调用一个接口看返回」，而是「订阅一个主题等消息」。等不到，就麻烦了——没有一个状态码告诉你为什么没等到。

至少有三个方向要查：

1. 根本没发。 发布方那一侧压根没把消息发出去，或者发了但没连上 Broker。
2. 主题写错了。 发布用的主题和你订阅的主题对不上。MQTT 的主题是分层的，还支持通配符，一个层级写错、通配符用错位置，消息就从你眼前流过去了而你收不到。
3. 权限不对。 Broker 上做了访问控制，这个客户端没有订阅该主题的权限，或者发布方没有发布权限。

三条方向，而不是一条。这也正是专用工具的价值所在——你需要同时开着「发布方视角」和「订阅方视角」，才能快速定位是哪一条。用一个只能填一组参数的界面来回切，排查效率会掉得很厉害。

顺带说一句 QoS。MQTT 的 QoS 分三级：0、1、2，分别对应不同强度的送达保证。这不是「越高越好」的滑块，等级越高意味着交互轮次越多。什么场景该用哪一级，取决于你的业务能不能容忍丢消息、能不能容忍重复消息，这是设计决策，不是调试选项。

关于 Apache-2.0 和 EMQ

MQTTX 的许可证是 Apache-2.0，这是一个宽松许可证：可以闭源商用，没有 copyleft 传染性（你用了它不意味着你的东西也得开源），并且带有专利授权条款。对企业采购和法务评审来说，这类许可证的阻力通常最小。

点到为止——具体到你公司的合规口径，以法务判断为准，这里不构成法律意见。

再说 EMQ 这家公司。EMQ 是做 MQTT Broker 的，MQTTX 是它的配套客户端工具。这个模式其实一点都不陌生：传感器厂商送你免费的调试软件，芯片厂商送你免费的烧录工具，逻辑是一样的——工具白送，钱在另一头。对 EMQ 来说，另一头是 Broker。

这不是什么需要警惕的事，客观陈述而已。免费开源的好工具，你拿来用就是了，它并不会因为出品方有商业产品就变差。只是心里有个数：工具的功能重心会倾向于把 MQTT 这件事本身做好、做顺，这恰恰是你需要的。

什么时候装它

回到最开始那条界线。

设备刚接上，你只想知道能不能连通、能不能收到那一条测试消息——手边的 NetAssist 或 SCOMM 打开就用，不用装新东西。串口那一头出问题的话，那是另一条线上的事，见串口调试工具和 UART 原理。

一旦你开始长期维护一套 MQTT 系统，或者需要把 MQTT 收发写进自动化流程，就该把 MQTTX 装上了。桌面版给你看得清，命令行版让它能进流水线，两件事都在官方发布里。

更多嵌入式与工业通信工具，见软件与工具库和在线工具。