STM32+ESP8266+MQTT接入阿里云：零基础物联网入门完整指南

简介：这是一套面向STM32物联网开发者的完整工程源码，解决基于STM32F103C8T6控制ESP8266模块，通过AT指令与MQTT协议接入阿里云物联网平台的核心需求。资源适合具备一定单片机基础、希望快速上手云接入开发的读者。压缩包共134个文件，主要包含34个h头文件与33个c源程序、Keil工程配置文件、编译生成的hex烧录文件以及中间编译产物，整体大小约3.17MB，结构完整可直接导入工程参考。已有8407人学习下载。源码中不仅提供阿里云服务器地址、设备三元组等关键桥接配置，还包含MQTT发布订阅主题设置以及标准外设驱动模块，能够帮助读者理清从硬件配置、AT指令交互到云端上下行数据全链路。文件分类清晰，便于对照学习每个功能模块，是一份适合物联网入门和毕业设计参考的实战资料。

1. 物联网新手第一课：stm32、esp8266、阿里云拼起来是什么

你手里有一块单片机开发板，想让它连上网，把温度发到手机上，或者远程按一下开关——听起来很“物联网”，可教程一打开全是 stm32、esp8266、AT指令、MQTT协议。我第一次看到也发怵。后来上手才明白，这套东西拆开没一个难：stm32 是“干活的人”，esp8266 是“上网的手机”，AT指令是暗号，MQTT 是设备跟阿里云对话用的“普通话”。

这篇就带零基础新手把名词逐个讲懂，走通一条完整链路：单片机连WiFi、上阿里云、上报数据、接收命令。对应的是一套现成的 stm32+esp8266+AT指令+MQTT 接入阿里云的完整源码，单片机端和云平台对接逻辑都在里面。你只要会最基础的 C 语言和烧录，就可以跟着边做边学。

2. 先搞懂四个概念：单片机、WiFi模块、AT指令、MQTT

2.1 STM32 单片机：一台没有网口的迷你电脑

STM32 本质上是一台很小的电脑。里面有处理器、内存、存储，能跑逻辑，能读传感器，能控制引脚输出高低电平。平时我们玩单片机点个灯、驱动个屏幕，用的都是这些能力。但有个明显短板：它没有网卡，也没有 WiFi 功能。换句话说，它会算、会控，但不会“上网”。

你可以把它想象成一个特别会算账的会计，账目做得清清楚楚，可手机没配，电话没装，想给别人报个数据都送不出去。物联网的核心诉求恰恰是“送出去”和“收回来”——把传感器数据送到云端，把远程指令收回来。所以需要给这个会计配一台“电话”，让他能把话说出去，也能听到外面的指令。这套系统里的电话，就是下面要说的 ESP8266。

那为什么大家学物联网都用 STM32 而不是别的单片机？原因有几点：一是资料实在太多，随便搜一个问题都有答案；二是外设丰富，串口、I2C、SPI、ADC 都有，接传感器很方便；三是生态成熟，从寄存器到标准库到 HAL 库都有对应教程。对新手来说，别纠结“选哪个型号最好”这种问题，先把手头这块 STM32 用起来，比什么都强。这套源码需要板子至少有一个串口用来连 ESP8266，一般上手板都满足。

2.2 ESP8266 WiFi 模块：给单片机配的“手机”

ESP8266 是一颗专门的 WiFi 芯片，本身也能跑程序，但在入门阶段，我们不用管它内部是怎么工作的，把它当“手机”用就行。手机有打电话、发短信的功能，我们只需要知道怎么“拨号”；ESP8266 一样，它把复杂协议栈藏在了内部，外部只暴露一个串口，我们通过串口发命令来指挥它联网。

这颗芯片便宜、体积小、功耗低，是这几年物联网入门最常见的模块之一。它支持 2.4GHz 频段的 WiFi 连接。日常使用中，只需把 ESP8266 接在 STM32 的某个串口上，这两个设备之间就能用一串约定的文本“暗号”来沟通——发一条命令给它，它回一个结果，这就是 AT 指令模式，也是这套源码里最核心的交互方式。

新手阶段最推荐的做法是：先在电脑上通过 USB 转串口线单独玩 ESP8266，确认它没有任何问题，再接到 STM32 上。这样做的好处是，出了故障时你能明确知道问题在模块还是在单片机，而不是两个都不确定的时候抓瞎。说实话这是我自己的血泪经验，当年我第一次把两样东西接在一起，WiFi 连不上还以为是板子坏了，排查半天才发现是模块供电不足。先把 ESP8266 单独弄明白，后面会省很多时间。

2.3 AT指令：机器之间的固定暗号

AT 这个词来自 “Attention”，是一套很老但依然通用的文本命令格式。它的核心思想是：主机通过串口向模块发送以 “AT” 开头的字符串，模块解析后执行动作，再返回一个结果（比如 OK 或 ERROR）。听上去很高端，其实很像你给朋友发消息：“晚上吃啥？” 朋友回：“火锅。” 一来一回，格式统一，谁也不会理解错。

AT 指令有几条最基本的规矩：每条指令以 AT 开头，不区分大小写（但一般习惯大写）；指令以回车换行 \r\n 结尾，模块才认为是“一条完整指令”；模块的返回值里常包含 OK，表示执行成功，ERROR 则表示失败。在串口助手里手动测试时，我们要勾选“发送新行”或者手动加回车，这一点新手特别容易忽略。

为什么要单独介绍这个？因为这套源码底层本质上就是在不停干同一件事：STM32 通过串口发出一条 AT 指令，然后解析 ESP8266 返回的字符串，判断是否成功。懂了这一点，读源码时会发现很多函数都是同一个套路——发指令、等回应、查关键词——接下来第四章我们会亲手试一遍。

2.4 MQTT协议：物联网世界的“广播站”

AT 指令解决的是“单片机怎么指挥模块”，而 MQTT 解决的是“设备到了云平台之后怎么通信”。MQTT 是一种消息协议，专为网络不稳定、设备性能不强的物联网场景设计。它的模型叫“发布/订阅”，我更喜欢把它比作广播站：每个设备都能往某个“话题”上发消息，也能订阅某个“话题”来收听消息。发消息的人不需要知道谁在听，听消息的人也不需要知道是谁发的，中间由服务器（在云平台这边）负责转发。

举个例子，你手上有个温度传感器，它把温度数据发到话题 “dev/device01/temp”，阿里云平台上对应的话题也订阅了这个名字，那么数据就会出现在云端。反过来，你在手机上下发一条“开灯”指令到 “dev/device01/control”，STM32 端订阅这个话题，收到后控制 GPIO 拉高，灯就亮了。

MQTT 的优势对单片机非常友好：报文非常轻量，一首古诗的字节数就够传一条消息；支持“遗嘱”和“保活”机制，能在设备异常掉线时让云端感知；发布与订阅解耦，设备只管发或收，不用关心对方是谁。阿里云物联网平台本身就以 MQTT 作为设备接入的主流方式，所以“stm32 + esp8266 + AT指令 + MQTT + 阿里云”这一整套，才被称为物联网入门的一条完整路线。

2.5 为什么新手要按这条组合学

可能有人会问：既然 ESP8266 本身就能跑程序，为什么还要外接 STM32？直接用 ESP8266 不更简单吗？确实可以，但那样学不到单片机端的外设和逻辑控制。物联网不只是“联网”，还要做传感器采集、电机控制、本地逻辑判断——这些恰恰是 STM32 的强项。ESP8266 负责通信，STM32 负责干活，两者配合，分工清晰，也更接近真实产品里的架构。

另一个原因是这条路线“每一层都看得见”。串口里能看到 AT 指令和返回值，网络上能看到 WiFi 是否连上，云平台上能看到设备有没有在线、消息有没有到达。每个环节都有明确的反馈，新手排查起来不会觉得这是个黑匣子。相比之下，一上来就学复杂的 TCP/IP 协议栈或射频知识，容易劝退。所以这套源码的设计，就是用最低的门槛，让你跑通一条真实的物联网链路。概念铺垫就到这里，下一步我们把工具备齐。

3. 动手第一步：先备好这些硬件和软件

3.1 硬件要准备什么

想把这套源码跑起来，硬件不需要多高级，按下面这份清单来就行，基本都是入门常用的东西：

• STM32 开发板：只要能跑、带一个串口即可。最常用来入门的是 STM32F103C8T6 这类小板，引脚少，资料多，价格低。
• ESP8266 模块：常见的是 ESP-01S 或者带 USB 底座的那种，建议买有 AT 固件的版本，到手就能用。
• USB 转 TTL 串口模块：这是调试 ESP8266 的“必经之路”，因为它能把电脑的 USB 信号转成串口电平，让 ESP8266 和电脑对话。芯片是 CH340 或 CP2102 都行。
• 几根杜邦线、一块面包板：不用焊，直接插线，方便调整。新手别一上来就用电烙铁，先用杜邦线搞通逻辑再说。
• 一个能提供 2.4GHz 信号的路由器，或者干脆用手机开热点（开 2.4GHz 频段，别开 5GHz）。这是因为 ESP8266 只支持 2.4GHz。

这些加起来成本不高，而且每样都能在后续物联网学习中反复用。稍微提醒一下：STM32 板子的供电和 ESP8266 的供电可能不是一路，调试时最好共地。所谓共地，就是把两个设备的 GND 接在一起，给它们一个共同的电压基准，否则串口信号会乱。很多新手卡在“收不到数据”上，最后发现不是程序问题，而是忘了共地。

3.2 软件要准备什么

硬件之外，软件只需要四样，功能其实都很单一：

• STM32 开发环境：一般用 MDK 或 STM32CubeIDE，任选一个。MDK 偏传统，很多教程都在用，打开工程直接编译下载；STM32CubeIDE 免费且跨平台。如果这套源码给你的就是某个 IDE 的工程文件，直接打开对应环境就行。
• 串口调试助手：用于在电脑上手动发 AT 指令给 ESP8266，查看返回结果。任何一个能收发串口的工具都可以，重点是把波特率选对。
• 串口驱动：如果你的 USB 转 TTL 模块用的是 CH340 或 CP2102 芯片，电脑识别不到串口时，要先装对应驱动。
• 一个记事本或笔记工具：用来记录配置信息，比如 WiFi 密码、设备三元组、Topic 名称。物联网接入失败，一大半原因就是配置信息抄错，这一点后文还会重点讲。

这些软件都不难找，而且大部分免费。建议初学者先别急着把所有软件装上，你只需要保证开发板和串口助手能正常工作就够了。环境越简单，越不容易出问题；等到真正烧录源码时，需要哪个再装哪个。

3.3 最重要的热身：让 ESP8266 先在电脑上独立跑起来

不少新手拿到源码后，第一件事就是把 ESP8266 直接插到 STM32 上烧录，结果程序跑起来没反应，完全不知道是模块没通还是代码问题。我强烈建议先做一个 10 分钟的热身测试：把 ESP8266 单独接到电脑上，用串口助手下指令，确认模块是好的。这套源码跑不跑得顺，取决于这个热身做没做扎实。

接线其实很简单：USB 转 TTL 的“发送（TX）”接 ESP8266 的“接收（RX）”，USB 转 TTL 的“接收（RX）”接 ESP8266 的“发送（TX）”，两个设备的 GND 接 GND，USB 转 TTL 的 3.3V 接 ESP8266 的 VCC。这里要提醒一句：ESP8266 的工作电压是 3.3V，绝对不要接 5V，一接基本就烧。如果你用的是带 3.3V 输出的 USB 转 TTL，直接供电；要是电流不稳，就外接一个 3.3V 稳压模块。

接好之后，打开串口助手，选对串口号，波特率设为 115200（大多数 AT 固件默认值），然后在发送框里输入 AT，记得勾选“发送新行”（也就是在指令后面自动加回车换行）。点击发送。如果模块正常，你会马上看到它返回一个 OK。看到 OK 的那一刻，你的物联网学习就算正式开始，因为这表示“模块能听懂人话了”。

3.4 热身结果怎么看：三种情况一次搞清

这里把热身时可能遇到的三种情况都提前说清楚，免得你去网上搜半天答案还搜不明白。

第一种：发送 AT，返回 OK。恭喜，模块正常，可以继续往下走。第二种：有返回，但全是乱码。多半是波特率不对，或者模块启动过程中你发了指令。可以先把波特率换成 9600 试试，或者在模块刚启动后稍微等一下，看到模块输出了 ready 这样的英文再操作。第三种：完全没反应。优先检查接线是不是接反了、GND 有没有接、3.3V 有没有供上、串口号有没有选错。另外要注意，某些 USB 转 TTL 模块上没有单独的 3.3V 引脚，或者输出电流太小带不动 ESP8266——如果发现模块一工作就重启，这就是供电不足的信号，换一个供电方式就行。

这几种情况，基本覆盖了模块不工作的绝大多数原因。把这个热身做透了，后面源码里的问题就好排查了。比如以后你发现源码跑起来但连不上 WiFi，至少能确定不是模块本身坏了，问题只可能出在配置或代码。从这个角度看，热身测试其实不是多余步骤，而是给你后面排查问题划了一条分界线。

4. 上机实操：用 AT 指令让 ESP8266 连上 WiFi

4.1 第一条指令：AT，跟模块打个招呼

一切从最简单的地方开始。确保串口助手还在连接状态、波特率正确、模块已通电，然后发送这条指令：

AT

正常情况下，模块会在几毫秒内返回：

OK

这两个字符的意义非同小可。它说明串口通路是好的、模块的 AT 固件是活的、供电是够的，前面所有硬件准备工作都成立。如果你发出去没有反应，别急着往下走，回到上一章把问题找到再继续。我见过不少同学在这个环节上一时卡住，后面的所有 AT 指令全跟着乱套，最后心态爆炸。AT 测试就是地基，地基不牢，后面全白搭。

需要注意的是，串口助手里发送 AT 时，一般要勾选“发送新行”或者“加回车换行”选项，让指令以 \r\n 结尾。AT 指令的解析器是靠回车换行来“断句”的，你发的字符串它收到了，但没收到结束符，它就不知道这条指令说完了，自然不会回 OK。这是一个非常容易被忽略的细节，尤其在用脚本自动发送时，很多人忘记加 \r\n，就会得到“指令发了但模块不理你”的诡异现象。

4.2 配置工作模式：AT+CWMODE

ESP8266 有三种工作模式：Station 模式（连接路由器的客户端模式）、AP 模式（自己开热点让别人来连）、以及 AP+Station 双模式。我们这套物联网链路里，设备要主动去连家里的路由器，也就是往阿里云方向走，所以要把模块设成 Station 模式。先看看当前是什么模式：

AT+CWMODE?

模块会返回类似：

+CWMODE:1 OK

数字的含义：1 代表 Station，2 代表 AP，3 代表 AP+Station。如果当前不是 1，我们把它设成 1：

AT+CWMODE=1

返回 OK 就说明设置成功了。这个模式是“记在模块里的”，设置过一次以后，重启模块它仍然生效，除非你重新改模式或恢复出厂设置。所以如果发现模块重启后连不上自家 WiFi，可以先查查工作模式是不是被谁改成了 AP 模式——这算是我踩过的一个小坑，曾经一个模块接在板子上总是自己开热点，后来才发现是之前试验时留下的配置。

4.3 连接 WiFi 网络：AT+CWJAP

模块现在是一个“等待联网的客户端”了，接下来让它去连接你家的路由器。指令格式是：

AT+CWJAP="你的WiFi名字","你的WiFi密码"

比如你的 WiFi 叫 myhome，密码是 12345678，就写成：

AT+CWJAP="myhome","12345678"

发送后，模块会开始扫描并连接，几秒后依次返回：

WIFI CONNECTED WIFI GOT IP

看到这两行，意味着 ESP8266 已经成功接入了局域网，并且从路由器那里拿到了一个内网 IP 地址。这里的 GOT IP 非常关键，因为它代表模块已经进入了“可通信”状态，后台上云就依赖这个基础。

如果返回的是 ERROR 或者一直卡在 CWJAP...，常见原因有三个：WiFi 密码不对、WiFi 名没加引号或引号格式错误、路由器开了 5GHz 频段而 ESP8266 只支持 2.4GHz。新手最容易纠结的是第三个——手机热点一般默认可能开 5GHz，模块搜不到，就会一直连不上。解决方法是把热点频段切到 2.4GHz，或者换个 2.4GHz 路由器试验。另外提醒一句：WiFi 名字和密码如果包含特殊字符，要注意引号内是否完整复制，空格也算字符，错一个都连不上。

4.4 验证联网成功：AT+CIFSR

连接成功之后，我们可以顺手查一下模块拿到的 IP 地址，发这条指令：

AT+CIFSR

模块会返回类似：

+CIFSR:STAIP,"192.168.1.100"

看到 192.168 开头的地址，说明它在局域网里已经有了正式身份，可以被路由器管理和互相通信了。到这一步，ESP8266 的单机联网测试可以说是完全跑通了。你可能会想：这不就是在电脑上手动发指令嘛？和 STM32 有什么关系？非常好，这个想法正是关键——后面我们要做的，就是让 STM32 通过串口把上面这几条指令自动发出来，代替你的手。逻辑完全一样，只是“发指令的人”从你换成了单片机。

下面列一张速查表，方便你在调试时随手翻。表里的指令是按顺序使用的，越靠前的越基础。拿到源码后如果发现程序卡在某一步，也可以对照这张表手动发一遍，确认模块在裸机状态下是否正常。

4.5 从手动到自动：让 STM32 替我们发指令

手动测试已经验证了整个流程可行，接下来就看源码里是怎么把“手动”变成“自动”的。在 STM32 工程里，通常会有一个专门的文件来封装 ESP8266 的指令发送。它做的事其实特别朴素：把一个字符串通过串口发出去，然后等待模块返回，再在返回内容里找我们关心的关键词。

举个最简单的发送函数例子：

// 通过 STM32 的串口发送一条 AT 指令 void esp8266_send_cmd(char *cmd) { // 把字符串内容逐字节发送给 ESP8266 HAL_UART_Transmit(&huart1, (uint8_t *)cmd, strlen(cmd), 1000); // 稍等一会儿，给模块留出处理时间 HAL_Delay(200); }

这个函数很直白：调用一次 HAL_UART_Transmit，把整个字符串发给串口；再延时 200 毫秒，等模块处理完。实际源码里可能还加上了发送 \r\n 的代码，正是因为前面说过，AT 指令必须以回车换行结尾，模块才认为这是一条完整指令。如果你在源码里看到类似sprintf(tmp, "AT+CWJAP=\"%s\",\"%s\"\r\n", ssid, pwd);这样的代码，不要觉得格式复杂，它只是在拼字符串——把 WiFi 名和密码嵌进 AT 指令里面去。

再看接收判断的部分。模块返回的内容往往带有换行、空格，我们不能指望它恰好就是 “OK” 两个字符，所以源码里更常见的做法是：

// 在串口收到的缓冲区里查找关键字，比如 "OK" uint8_t esp8266_wait_response(char *keyword) { // 如果缓冲区里能找到目标关键词，说明指令执行成功 if (strstr(rx_buffer, keyword) != NULL) { return 1; } return 0; }

这里用到的 strstr 是 C 语言字符串查找函数，它在 rx_buffer 这个接收缓冲区里找 keyword 这个子串，找到了就返回非空指针。之所以用“找关键词”而不是“完全相等”，是因为 AT 模块返回的真实数据里通常还有别的字符，比如回车换行、状态信息等。你只关心有没有 OK，所以只要缓冲区里出现 OK 就算通过。理解了这个套路，再看源码里那些 send_cmd、wait_response 的组合，会突然觉得哪里都熟悉——本质上就是把你在串口助手里干的事，搬到了单片机里自动执行。

5. 避坑手册：新手最容易踩的五个坑

5.1 现象：ESP8266 一工作就重启

模块在连接 WiFi 的过程中会进入高功耗状态，如果你用的是 USB 转 TTL 模块直接供电，很可能发现模块刚有反应就开始闪烁重启、或者串口突然失去连接。原因很简单：ESP8266 瞬间电流可以到几百毫安，普通串口工具的 3.3V 引脚供不出这么大电流，电压一掉，模块就复位了。

解决方法是给它单独供电：用一路可靠的 3.3V 电源给 ESP8266 供电，同时把这路电源的 GND 与 STM32/串口工具的 GND 接到一起。如果手头没有独立稳压模块，至少换一个输出能力更强的 USB 转 TTL，或者给模块加一个大一点的电容稳住电压。记住一个原则：VCC 可以分开供，GND 必须共地，不然串口信号的电平参考就会乱。

5.2 现象：发送 AT 返回乱码或直接没反应

这是大家在串口调试阶段碰到的头号问题。乱码的原因，第一是波特率不对。AT 固件最常用的默认波特率是 115200，但部分模块或老固件可能是 9600，两者发出来的字符互相看不懂，自然全是乱码。第二是发指令的时机不对，模块上电启动时需要一两秒初始化，启动过程中串口会输出一些日志，你此时发 AT 可能被淹没。

没反应的原因通常出在接线上：TX 和 RX 必须交叉连接，也就是 A 的 TX 接 B 的 RX，B 的 RX 接 A 的 TX。很多第一次接线的同学会把两根线接成直连，结果收不到任何数据。解决方法很机械——先把波特率换一遍试，然后检查接线，最后确认发送时勾选了“发送新行”。不要同时改多个变量，一次只改一个，问题很快就能定位。

5.3 现象：AT+CWJAP 一直返回 ERROR 或连不上 WiFi

如果你已经确定模块本身能通信，但连接 WiFi 时失败，原因大概率集中在三处。第一处是路由器频段问题：模块只支持 2.4GHz，5GHz 信号对它来说就像广播里的外语频道，根本搜不到。第二处是密码或 SSID 写错，AT 指令对引号和大小写敏感，密码里的大写、小写、空格都要严格一致。第三处是模块之前记录了错误配置，重启后还在用旧参数连接。

排查顺序建议这样：先用手机开一个 2.4GHz 热点，手动发 AT+CWJAP 去连热点。如果连手机热点都失败，再逐步检查密码和引号；如果连热点成功了但连家里路由器失败，那就是路由器设置的问题，看看是否开启了设备白名单或 MAC 过滤。这一步的目标不是“碰运气”，而是通过控制变量缩小范围。

5.4 现象：MQTT 连接云平台一直失败

到了接入阿里云这一步，很多人的程序会卡在 MQTT 连接不上。老实说，这个问题很大概率都出在配置信息：云平台给每个设备分配了三个关键参数——ProductKey、DeviceName、DeviceSecret，也就是常说的“三元组”。这三个值只要错一个字母、大小写不对、或者是把别的小组里的设备参数复制了过来，云端建立连接时就会直接拒绝。

解决方法是逐项核对：先确认你用的是不是自己项目下的设备三元组；再确认 MQTT 接入地址和设备证书对应的区域是否一致；最后确认源码里这三个参数有没有被正确拼进连接指令里。由于 AT 指令是文本命令，如果三元组里有特殊字符，源码里通常还要用转义符号处理，比如把引号改成\"。遇到连接失败时，先别怀疑协议，把三元组从头到尾对三遍，绝大多数问题当场就能解决。

5.5 现象：云端看不到数据，但模块显示已经连接

还有一种更常见的情况：设备在云平台显示的在线状态是正常的，串口里也偶尔能看到模块返回成功，但云平台的设备日志里就是一条消息都没有。这多半不是“没连上”，而是“上报错对象”了。MQTT 的数据要发到指定的 Topic（主题），如果你发的 Topic 和云平台上定义的不一致，平台会认为这是非法消息，直接丢弃，或者因为消息格式（比如 JSON 字段名）对不上，无法解析入库。

解决方法是回到云平台控制台，找到你产品的 Topic 列表和消息格式说明，逐个对比源码里填写的 Topic 名称、消息内容字段。注意 Topic 里有时会包含设备名变量，如果你的 DeviceName 写错了，Topic 对不上也收不到。建议先在云平台手动发布一条测试消息给设备，确认设备能否收到，再反过来查设备上报方向的数据。这样半个小时后一定能定位到问题，而不是干瞪眼。

6. 下一步怎么走：把源码跑起来之后学什么

当你看到设备在云平台上显示“在线”，并且能收到上报的数据时，恭喜你，你已经越过了新手最大的心理门槛。这套源码给的不只是一个能跑的程序，更是一张地图——接下来的学习，建议沿着下面三步走。

第一步是“照烧”。先把源码原封不动烧进板子，不要改任何功能，重点观察串口打印和云平台状态。第二步是“小改”。把固定的温度改成传感器读取的真实值，把云平台下发的指令用来点亮板载 LED，这两个改动都有源码可以参考。下面这张表是源码投入使用前最需要确认的三个地方：

第三步是“自己写”。把源码里的 MQTT 相关部分遮住，凭记忆重新实现一遍数据上报。这一步才是真正把知识变成能力的关键。之后再学 DHT11 温湿度传感器、继电器控制、设备影子、OTA 升级，方向就都很清晰了。

以前带 A 同学学这块时，他嫌 AT 调试麻烦，上来就直奔 MQTT，结果连不上、收不到、报错全赶到一起，最后老老实实从 AT 测起，反而半天就通了。从那以后我每次拿到新模块，都强制自己先走一遍“单独上电、串口测试、连路由器”三步，再进项目逻辑。这套习惯帮我省掉了大量排查时间，希望也能帮到你。

本文还有配套的精品资源，点击获取