4. 订阅端通配符误匹配排查

问题场景：一条“水位”订阅为何收到瓦斯数据

矿山监控端常把订阅写成 mine/+/alarm 或 mine/# 这类通配符形式，本意是“订阅所有分站的报警”。但 MQTT 的 + 只匹配单个层级，# 匹配该层级及其以下所有层级，一旦层级设计不一致，就会把无关主题一并收进来。典型现象是：水位监测客户端订阅 mine/water/+/alarm，却持续收到 mine/gas/station01/alarm 的消息，导致告警面板出现“水位报警”误报。

本例用一个可复现的最小主题树来定位误匹配：先构造会“串台”的订阅过滤器，观察实际收到的主题，再对照主题树逐层比对，最后把过滤器改成精确匹配。

复现误匹配：用 mosquitto_sub 观察实际收到的主题

在本地 Broker（监听 1883）上，先让三个“传感器”分别向不同主题发布，再用错误过滤器订阅，观察 -v 输出的主题名。这里用 %t 打印主题，便于逐条比对。

# 终端 A：发布三条不同业务的消息（各发一次，QoS 1）
mosquitto_pub -h 127.0.0.1 -p 1883 -q 1 -t mine/water/station01/alarm -m "water=1.2m"
mosquitto_pub -h 127.0.0.1 -p 1883 -q 1 -t mine/gas/station01/alarm   -m "ch4=0.8%"
mosquitto_pub -h 127.0.0.1 -p 1883 -q 1 -t mine/vent/fan01/state      -m "fan=on"

# 终端 B：错误过滤器，观察实际收到的主题
mosquitto_sub -h 127.0.0.1 -p 1883 -q 1 -t 'mine/+/alarm' -v
# 预期输出（示例）：
# mine/water/station01/alarm water=1.2m
# mine/gas/station01/alarm   ch4=0.8%     ← 误匹配，水位端不应收到

关键判断：mine/+/alarm 只有 3 层，而实际主题是 4 层（mine/water/station01/alarm），+ 只吃掉一层，因此该过滤器根本匹配不到 4 层主题；真正会串台的是 mine/# 或 mine/+/+/alarm 这类层级数对得上的写法。下面用 mine/+/+/alarm 复现真正的误匹配。

mosquitto_sub -h 127.0.0.1 -p 1883 -q 1 -t 'mine/+/+/alarm' -v
# 预期输出（示例）：
# mine/water/station01/alarm water=1.2m
# mine/gas/station01/alarm   ch4=0.8%     ← 误匹配确认

用主题树逐层比对定位误匹配规则

把订阅过滤器按 / 拆成层级，与实际主题逐层对齐，是定位误匹配最直接的方法。下表以 mine/+/+/alarm 为例：

结论：第 2 层的 + 是误匹配根源，它把 water 和 gas 都放行了。修正方式是把第 2 层写死为业务域 water，即 mine/water/+/alarm。

修正订阅过滤器并验证

# 修正后：第 2 层固定为 water，仅第 3 层用 + 匹配分站
mosquitto_sub -h 127.0.0.1 -p 1883 -q 1 -t 'mine/water/+/alarm' -v
# 预期输出（示例）：
# mine/water/station01/alarm water=1.2m
# （不再出现 mine/gas/... 的消息）

验证通过条件：连续发布上述三条消息各 3 次，订阅端只应出现 mine/water/station01/alarm 共 3 条，mine/gas/... 与 mine/vent/... 计数为 0。若仍有串台，检查是否在客户端代码里同时保留了旧的 mine/# 订阅——MQTT 允许同一客户端存在多个订阅，旧过滤器不取消就会继续收消息。