1. MQTT 基础回顾：发布/订阅模型、主题与通配符、QoS等级、会话与遗嘱消息
各位同学，咱们正式开始之前，先把地基夯实。MQTT 的核心概念，说白了就这几块。我见过不少新手，上来就配权限，结果连主题通配符都搞混，最后 Broker 直接崩了。嗯，咱们今天把这几个点彻底理清。
1.1 发布/订阅模型：谁说话，谁听
MQTT 不是传统的客户端到服务器直连。它用的是发布/订阅模型。什么意思？
- 发布者（Publisher）：只管发消息，不关心谁收。
- 订阅者（Subscriber）：只管收消息，不关心谁发。
- Broker：中间人，负责转发。
我在一个智慧工厂项目里，传感器只负责上报温度，控制台只负责接收告警。两边完全解耦。你想想看，如果哪天要换传感器，订阅者根本不用改代码。这就是发布/订阅的魅力。
核心要点：发布者和订阅者不需要知道对方存在。所有通信都通过 Broker 中转。
1.2 主题（Topic）与通配符：消息的地址
主题就是消息的“地址”。它用斜杠分层，比如 factory/floor1/temperature。订阅者可以精确订阅，也可以用通配符批量订阅。
两种通配符
| 通配符 | 含义 | 示例 | 匹配结果 |
|---|---|---|---|
+ |
单层通配 | factory/+/temperature |
匹配 factory/floor1/temperature，不匹配 factory/floor1/room1/temperature |
# |
多层通配 | factory/# |
匹配 factory/floor1/temperature 和 factory/floor1/room1/humidity |
注意：# 只能放在主题末尾，比如 factory/# 合法，factory/#/temp 非法。我曾经见过有人把 # 放中间，结果 Broker 直接报错，排查了半天。
我个人习惯，在设计主题树时，尽量用 + 而不是 #。为什么？因为 # 权限太大，容易泄露不该泄露的数据。后面讲授权策略时，你会深有体会。
1.3 QoS 等级：消息到底可靠不可靠？
QoS（Quality of Service）决定消息的送达保证。MQTT 有三个等级。
| QoS | 名称 | 发送次数 | 适用场景 |
|---|---|---|---|
| 0 | 至多一次 | 1 次（发完即忘） | 传感器高频数据，丢一帧无所谓 |
| 1 | 至少一次 | 至少 1 次（可能重复） | 控制指令，必须到达，允许重复 |
| 2 | 恰好一次 | 4 次握手 | 支付、计费，不能丢也不能重复 |
我在做车联网项目时，车辆状态用 QoS 0，因为数据量大，丢几帧不影响。但远程锁车指令必须用 QoS 2，一次都不能错。你想想看，要是锁车指令丢了，后果多严重。
避坑指南：QoS 2 性能开销大，别滥用。我曾经有个同事，把所有消息都设成 QoS 2，结果 Broker 内存爆了。后来改成 QoS 1 + 去重逻辑，问题解决。
1.4 会话与遗嘱消息：连接断了怎么办？
MQTT 的会话分两种：清洁会话和持久会话。
- 清洁会话（Clean Session = true）：断开后，Broker 清空所有会话信息。下次连接重新开始。
- 持久会话（Clean Session = false）：断开后，Broker 保留订阅和离线消息。重连后自动恢复。
遗嘱消息（Will Message）是啥？就是客户端在连接时，告诉 Broker：“如果我挂了，帮我发这条消息。” 比如一个温度传感器突然掉线，Broker 可以自动发布 sensor/status/offline，让监控系统知道。
实战经验：我在智能家居项目里，每个设备连接时都设置遗嘱消息。设备掉线后，Broker 自动更新设备状态。这样控制面板永远显示真实状态，不会出现“设备在线但实际已断”的假象。
1.5 知识体系总览
下面这张图，把今天讲的核心概念串起来。你可以把它当作本章的“地图”。
这张图里，发布者把消息扔给 Broker，Broker 根据主题找到订阅者，再按 QoS 等级推送。同时，会话和遗嘱消息保证连接断开时的行为可控。嗯，这就是 MQTT 的骨架。
1.6 小结
今天咱们把 MQTT 的五个核心概念过了一遍。发布/订阅模型让你解耦，主题和通配符让你灵活订阅，QoS 让你控制可靠性，会话和遗嘱让你处理异常。这些是后面所有授权策略的基础。