3. MQTT协议基础：发布/订阅模型、QoS等级、Topic与Payload设计原则

MQTT这玩意儿，说白了就是物联网世界的"消息快递"。我最早接触它是在一个智能农业项目里，几十个传感器节点要往服务器上报数据，用HTTP？太笨重了。MQTT一上手，我就知道对了。

它最核心的思想就三个：轻量、异步、解耦。你不需要知道数据发给谁，也不需要等对方回应。发完就干别的事去。这在嵌入式设备上太重要了——ESP32那点资源，经不起折腾。

3.1 发布/订阅模型：谁说话，谁听话

传统通信模型里，客户端直接连服务器，点对点。MQTT不一样，它中间加了个"经纪人"——Broker。

我习惯这么理解：发布者就是广播电台，Broker是信号塔，订阅者是收音机。你调对频率，就能听到想听的内容。

这种模型最大的好处是解耦。发布者和订阅者不需要知道对方存在，甚至不需要同时在线。我在一个工厂项目里，传感器半夜上报数据，服务器白天才处理——完全没问题。

3.2 QoS等级：消息到底靠不靠谱？

MQTT定义了三个服务质量等级。你想想看，在物联网场景里，有些数据丢了无所谓，有些丢了要出大事。QoS就是干这个的。

我的建议是：能用QoS 0就别用1，能用1就别用2。QoS 2的开销很大，每次消息要来回4个报文。在ESP32上，除非是绝对关键的数据，否则别碰QoS 2。

3.3 Topic设计：消息的"地址"怎么写？

Topic就是消息的主题，Broker靠它来路由消息。设计Topic就像设计文件目录，搞乱了后面全是坑。

我见过最糟糕的Topic设计：sensor1、data2、temp3……项目一大了，根本没法维护。

设备类型/位置/传感器/动作
例如：
esp32/room1/temperature
esp32/room1/humidity
esp32/room2/led/set

Topic支持两个通配符：

• +：匹配单层。比如 esp32/+/temperature 匹配所有房间的温度
• #：匹配多层。比如 esp32/# 匹配所有ESP32设备的所有消息

3.4 Payload设计：消息体里装什么？

Payload就是消息的内容。MQTT对Payload格式没限制，你可以传纯文本、JSON、二进制、甚至图片。但怎么设计，直接影响系统性能。

我推荐JSON格式，原因很简单：可读性好，解析方便，ESP32上也有现成的库。

举个例子，一个温度传感器的Payload：

// 不好的设计
{"t": 25.3}

// 好的设计
{
  "device_id": "esp32_001",
  "type": "temperature",
  "value": 25.3,
  "unit": "celsius",
  "timestamp": 1700000000
}

你可能会问：第一个不是更省流量吗？没错，但调试的时候你根本不知道这个"t"是什么。我吃过这个亏——线上问题排查，日志里全是"t":25.3，鬼知道是温度还是时间戳。

3.5 综合设计示例：一个完整的MQTT通信

假设我们要做一个智能灯控系统，来看看完整的Topic和Payload设计：