简要回答

粘贴一个 MQTT 主题名或订阅过滤器，即可查看一组结构和策略信号。检查器会标记空层级、位置不当的多层通配符 #、过于宽泛的单层通配符 +、疑似敏感词、不明确的消息意图，以及过深的层级结构。检查通过仅表示这些启发式规则未发现明显问题。

代理授权仍然是最终控制手段。需使用生产环境中的身份、租户、客户端类型和代理配置，对允许和拒绝的操作进行实际测试。

输入内容

请分别检查主题名和订阅过滤器。主题名是附加到发布的应用消息上的字符串，不能包含通配符。订阅过滤器可以包含 +（匹配单层）或 #（匹配剩余所有层），但需遵循 MQTT 的位置规则。

使用真实的结构，但替换掉可能暴露客户、人员、设施、凭据或内部命名的标识符。例如：

v1/acme/device-42/telemetry

或：

v1/acme/+/status

检查器不需要代理地址、用户名、密码、证书或载荷。

检查项

当前实现采用可读的确定性规则：

  • 前导斜杠、尾随斜杠或双斜杠会产生空的主题层级。
  • 除非 # 是整个过滤器或位于 / 之后的最后一个层级，否则会被标记。
  • 超过一个 + 会被视为宽泛的订阅范围，需要明确审查。
  • 包含 password、secret、token、email 等词时会触发敏感数据警告。
  • 如果没有任何层级类似于 telemetry、event、command、ack、state 或 status，检查器会提示是否需要体现消息方向或意图。
  • 层级超过八层时会提示审查层级中是否嵌入了可变元数据。

这些是设计提示，而非完整的 MQTT 解析器。多个 + 的警告是刻意保守的：对于管理型消费者，多个单层通配符可能是合理的；而对于设备身份，同样的过滤器可能不可接受。

示例分析

v1/acme/device-42/telemetry 不会返回明显的结构问题。各层级非空，层级结构紧凑，末层体现了消息意图。但你仍需证明设备 42 只能在自己的租户和身份边界内发布，且无法订阅其他设备的遥测数据。

/acme/+/+/data/#/archive 会产生多个审查点：以空层级开头，包含多个 + 通配符，# 位于非末层，且使用 data 而非明确的方向或意图词。修复语法问题并不能自动使授权范围变得安全。

局限性

检查器不会连接代理或检查 ACL。它不验证 UTF-8 约束、空字符、保留的 $ 命名空间、共享订阅语法、主题别名、最大包大小、代理特定限制、规范化、同形异义字，也无法区分所有合法的主题名和过滤器。它同样无法判断某个租户 ID、设备 ID 或操作是否应放在特定层级。

不要将检查结果作为客户端已隔离的证据。构建反向测试，尝试跨租户发布、跨设备订阅、通配符越权、留存消息访问和系统主题访问。在代理规则无法表达业务边界的地方，保留应用层授权。

隐私与分享

主题输入完全保留在浏览器中，并刻意排除在 URL、复制参数集和导出参数之外。这样可以防止分享功能将可能敏感的层级结构写入浏览器历史或 Referer 数据。结果摘要仍可复制或导出为 JSON、CSV 或 Markdown，但仅包含启发式检查的结论。

页面不会用你的主题发起任何网络请求。但请避免输入生产环境密钥——主题路径本就不应包含这些内容。

常见问题

多个 + 是无效的 MQTT 吗？

不是。检查器标记它是因为它扩大了订阅范围。是否可接受取决于客户端角色和授权策略。

为什么合法的过滤器仍然会收到警告？

语法合法和最小权限是不同的问题。一个过滤器可能合法，但对于使用它的身份来说过于宽泛。

此工具能测试 ACL 吗？

不能。请使用配置好的代理，配合允许和拒绝的身份进行集成测试。如相关，还需包含留存消息和 $ 主题。

相关指南

使用设计 MQTT 主题层级来选择稳定的层级、分离命令与事件、保持租户边界，并在编写代理规则前规划版本策略。