如果你最近翻过对标 CAPS 的《编程与机器人》教学大纲，或者试着为自己的课堂设计一节物联网（IoT）实操课，多半已经撞见过 MQTT 这个缩写，以及那句“需要一台 MQTT 代理服务器”的要求。在信息技术老师或者本就忙得团团转的技术主管看来，这纯属没必要的复杂。ESP32、Raspberry Pi Pico W 这样的单片机，为什么不能直接通过本地 Wi-Fi，把传感器数据发到学生的笔记本或者手机上？

简短的回答是：设备之间直连既脆弱又吃资源，而且几乎完全过不了学校网络安全那一关。MQTT（消息队列遥测传输）的解法，是把数据的发送方和接收方拆开，所有消息都交给一个叫作代理服务器的中央管理者转发。它是工业物联网的行业标准，如今在课堂的实体计算里也越来越不可或缺。

教室里的公告板：读懂发布／订阅

要明白 MQTT 为什么管用，不妨设想一间坐了 40 名学生的教室。如果每个想知道室外气温的学生，都得走到靠窗那位同学跟前问一句“现在几度”，那位靠窗的同学整节课就只能反复回答同一个问题，自己的事一样也做不成。要是又有十个学生想知道下一次课间什么时候开始，他们就只能直接打断老师。

现在，在走廊里立一块公告板。靠窗的同学在便签上写下“气温：22°C”，贴到“天气”这个标题下面。老师把“下次课间：10:30”贴在“作息”下面。谁想知道气温或者课间时间，走到板子跟前看一眼就行。靠窗的同学不知道、也不关心是谁在看气温，他只管把最新数值贴上去。看的人也不必去打扰他。

这就是 MQTT 采用的发布／订阅（Pub/Sub）模型：

• 发布者：接了传感器、把数据发给代理服务器的那块单片机（也就是靠窗的同学）。
• 订阅者：想要收到这些数据的仪表盘、手机 App 或者数据库（也就是看公告板的学生）。
• 代理服务器：接收发布者的消息、再转发给对应订阅者的中央服务器（也就是那块公告板）。

技术内核：主题、保留消息与遗嘱消息

即便无线连接质量很差，MQTT 也要靠三个核心概念，把通信维持得高效而可靠。

1. 主题：消息不是发给某台具体设备的，而是发布到“主题”上。主题用正斜杠分层，形如 school/lab1/temp 或者 home/garden/moisture。设备可以订阅一个非常具体的主题，也可以用通配符一次监听多个主题。比如订阅 school/+/temp，一块仪表盘就能显示全校每一间实验室的温度读数。

2. 保留消息：正常情况下，传感器发布一个读数时，如果那一毫秒恰好没人订阅，这条消息就永远丢了。学生五分钟后打开仪表盘 App，看到的会是一片空白，直到传感器再发一次为止。给消息置上“保留”标志，发布者其实是在告诉代理服务器：“把最后这个值存着。下次谁订阅这个主题，立刻把它给他。”对于土壤湿度、水箱液位这类变化缓慢的数据，这一点至关重要。

3. 遗嘱消息（LWT）：在南非的教室里，单片机时不时就会突然掉线——拉闸限电、电池没电，或者学生不小心把电源线拽了出来。设备第一次连上代理服务器时，会登记一条“遗嘱”消息（比如主题 status/sensor1，内容 offline）。一旦设备骤然断电、来不及发出正常的断开信号，代理服务器就会察觉连接已断，替它自动把这条“遗嘱”消息发布出去，告诉系统其余部分：这台硬件已经离线。

学校网络上会出岔子的三件事

MQTT 本身足够健壮，但要在教育环境里落地，就得直面学校 IT 基础设施的现实。有三种常见的失效方式，会隔三差五地把一节课搅黄：

学校网络上的常见故障

要绕开这些本地网络的坎，教育工作者一般只有两条路可选：要么去跟 IT 部门磨，让他们改路由器配置；要么把流量交给一台部署在云端、可通过标准 Web 端口访问的外部代理服务器。如果老师想要的是一套干脆利落、拿来就能上课、彻底免去本地网络这些麻烦的方案，Sheen IoT 平台提供了预先配置好的云端 MQTT 环境，它本就是照着学校防火墙的种种限制设计的。

把消息传递的担子从单片机挪到专门的代理服务器上之后，即便学生的代码没怎么优化，或者学校的 Wi-Fi 抖了一下，MQTT 也能让教室里的物联网设备可靠而安全地通信。