1. 系统架构与通信链路解析

在嵌入式物联网应用中，构建一个具备双向控制与数据上报能力的远程监控系统，关键在于厘清各组件间的职责边界与数据流向。本方案采用分层解耦设计：STM32F103C8T6作为边缘感知与执行节点，负责温度采集、LED状态控制及本地协议封装；ESP-01S作为网络接入单元，承担WiFi连接管理、MQTT协议栈运行与云平台通信；阿里云IoT平台作为云端中枢，提供设备认证、消息路由、规则引擎与Web可视化界面。三者之间通过UART串口建立确定性通信链路，形成“感知—传输—决策—反馈”的闭环。

该架构的核心优势在于职责分离。STM32无需处理复杂的TCP/IP协议栈或TLS加密，避免了资源受限MCU在内存与算力上的瓶颈；ESP-01S则专注于其擅长的网络层操作，将底层通信细节对MCU透明化。这种分工使系统具备良好的可维护性与可扩展性——后续若需增加光照传感器或继电器输出，仅需修改STM32端的数据采集与打包逻辑，而网络接入层保持不变。

整个数据流分为上行与下行两个方向：
- 上行路径（数据上报） ：DS18B20温度传感器通过单总线协议向STM32返回12位温度值 → STM32经HAL库ADC或GPIO模拟读取后，按预定义JSON格式序列化（如 {"method":"thing.event.property.post","params":{"temperature":25.6},"id":"12345"} ）→ 通过USART2以9600波特率发送至ESP-01S的RX引脚 → ESP-01S解析并封装为MQTT PUBLISH报文 → 经由WiFi连接至手机热点，最终发布至阿里云IoT平台指定Topic。
- 下行路径（指令下发） ：用户在阿里云IoT控制台点击“LED ON”按钮 → 平台生成MQTT消息并推送至设备订阅Topic → ESP-01S接收PUBLISH报文后剥离MQTT头，提取有效载荷（如 {"method":"thing.service.property.set","params":{"led":1}} ）→ 通过USART2以相同波特率转发至STM32的RX引脚 → STM32在中断服务函数中解析JSON，识别 led 字段值 → 调用HAL_GPIO_WritePin控制GPIOA_Pin5电平翻转，驱动LED点亮。

这种明确的分层结构决定了调试必须遵循自底向上原则：先确保STM32与ESP-01S之间的UART通信可靠，再验证ESP-01S与阿里云的MQTT连接稳定性，最后联调全链路功能。任何跳过中间环节的“端到端”调试，都会因故障点模糊而导致数小时无效排查。

2. 硬件连接与电气特性约束

硬件连接是系统稳定运行的物理基础，绝非简单的线缆对接。本方案涉及三个关键接口：USB转TTL串口模块与ESP-01S的调试连接、ESP-01S与STM32的主通信连接、以及STM32最小系统自身的供电与复位设计。每一处连接都需满足严格的电气规范，否则将引发通信丢包、设备反复重启甚至芯片IO口永久性损伤。

2.1 USB转TTL模块与ESP-01S调试连接

USB转TTL模块（常见型号CH340G/CP2102）用于PC端串口助手与ESP-01S的初始配置。连接时必须注意三点：
- 电压匹配 ：ESP-01S工作电压为3.3V，其TX/RX引脚耐受电压上限为3.6V。若使用标称5V的USB转TTL模块，必须确认其输出电平是否为3.3V TTL（部分模块通过跳线帽切换），否则5V信号直接注入ESP-01S RX引脚将导致IO口击穿。实测中曾因误用5V模块，造成两片ESP-01S无法响应AT指令。
- 交叉连接 ：PC端USB转TTL的TX引脚必须连接ESP-01S的RX引脚，USB转TTL的RX引脚连接ESP-01S的TX引脚。这是全双工UART通信的基本要求，接反将导致无法收发。
- 共地连接 ：USB转TTL模块的GND必须与ESP-01S的GND可靠短接。未共地时，两者间存在电位差，导致信号参考电平漂移，表现为串口助手中出现乱码或完全无响应。建议使用万用表通断档实测GND连通性。

标准连接关系如下表所示：

USB转TTL模块	ESP-01S	说明
VCC (3.3V)	VCC	供电，严禁接5V
GND	GND	必须共地
TX	RX	PC发送，ESP接收
RX	TX	PC接收，ESP发送

2.2 ESP-01S与STM32主通信连接

此连接是系统数据交换的生命线，其可靠性直接决定整体功能成败。连接要点包括：
- 电平兼容性 ：STM32F103C8T6的USART2_TX（PA2）与USART2_RX（PA3）默认为5V容忍（5V-Tolerant）IO口，可安全接收3.3V电平信号。但ESP-01S的TX引脚输出3.3V电平，而STM32的TX引脚输出为VDD=3.3V，故两者电平天然匹配，无需电平转换电路。这是选择该MCU型号的重要考量。
- 引脚映射 ：务必确认STM32代码中初始化的USART外设与物理引脚一致。例如，若原理图将ESP-01S的RX连接至STM32的PA9，则代码中必须使用USART1而非USART2，并正确配置GPIOA_Pin9的复用功能。常见错误是代码配置USART2（对应PA2/PA3），而硬件却接在PA9/PA10，导致“硬件接对了，软件死活不通”。
- 电源隔离 ：ESP-01S在WiFi连接与数据传输时峰值电流可达300mA，远超STM32 LDO的带载能力。若共用同一LDO供电，ESP-01S工作时将导致STM32供电电压跌落，引发复位或ADC采样失真。必须为ESP-01S单独配置3.3V/500mA LDO（如AMS1117-3.3），并通过0Ω电阻与STM32电源网络物理隔离。在PCB布局中，ESP-01S的电源走线应粗短，并在其VCC与GND间放置10μF钽电容+100nF陶瓷电容组合去耦。

2.3 STM32最小系统关键设计

最小系统虽简，但几处设计缺陷足以让整个项目停滞：
- 复位电路 ：10kΩ上拉电阻与100nF电容构成RC复位电路，时间常数需大于STM32内部复位脉冲宽度（典型值2.5μs）。若电容过大（如10μF），上电后复位信号持续时间过长，导致系统启动缓慢甚至被误判为复位失败。
- 晶振负载电容 ：8MHz HSE晶振需配20pF负载电容。实测发现，若使用22pF电容，系统在高温环境下易出现时钟抖动，进而导致USART波特率偏差超过±3%，引发通信帧错误。严格按芯片手册推荐值选型是保障时钟精度的前提。
- BOOT引脚配置 ：STM32启动模式由BOOT0与BOOT1引脚电平决定。正常运行时，BOOT0必须接地（GND），BOOT1可悬空或接GND。若BOOT0意外浮空，上电时可能被干扰为高电平，导致芯片从系统存储器启动，执行内置Bootloader而非用户程序，表现为“下载成功却无任何反应”。

3. STM32端固件开发详解

STM32固件是整个系统的感知与执行核心，其设计需兼顾实时性、鲁棒性与可维护性。本节基于STM32CubeMX生成的HAL库框架，详细阐述温度采集、LED控制、串口通信三大模块的实现逻辑与关键参数设定依据。

3.1 温度采集：DS18B20单总线协议实现

DS18B20采用寄生电源模式，仅需一根数据线（DQ）即可完成供电与通信，极大简化硬件设计。但其时序要求严苛，任意一个脉冲宽度误差超过±1μs，都将导致ROM读取或温度转换失败。

3.1.1 GPIO模拟时序的关键控制点

HAL库未提供DS18B20专用驱动，需通过GPIO模拟单总线时序。核心在于精确控制引脚电平翻转时间：
- 初始化时序 ：主机拉低480μs以上，然后释放总线，等待15~60μs后采样。若从机存在，将在15~60μs内拉低总线60~240μs作为存在脉冲。此处延时必须使用 __NOP() 内联汇编或 HAL_Delay() 的微秒级变体（如 HAL_Delay(1) 实际为1ms，不可用），推荐使用SysTick定时器配置1μs中断，在中断服务函数中计数实现精准延时。
- 读写时序 ：写“1”时，主机拉低1~15μs后释放；写“0”时，拉低60~120μs后释放。读操作中，主机拉低1~15μs后释放，15μs后采样总线电平。所有操作均需在严格的时间窗口内完成。

3.1.2 温度转换与数据解析流程

一次完整温度测量包含以下步骤：
1. 复位与存在检测 ：执行初始化时序，确认至少一个DS18B20在线。
2. 跳过ROM命令（0xCC） ：若总线上仅有一个传感器，可跳过ROM搜索，直接发送此命令。
3. 启动温度转换（0x44） ：发送命令后，DS18B20开始转换，最大耗时750ms（12位精度）。此时主机可进入低功耗模式或执行其他任务。
4. 再次复位 ：为读取结果做准备。
5. 读取暂存器（0xBE） ：连续读取9字节，其中第0、1字节为温度值（LSB、MSB），第2~8字节为CRC校验与配置信息。
6. CRC校验 ：使用Dallas提供的CRC8算法（多项式0x18）校验前8字节。若校验失败，丢弃本次数据，避免将错误温度值上报云端。

温度值计算公式为： Temperature = (MSB << 8 | LSB) * 0.0625 。例如，读取到 0x01 0x40 ，则温度为 (0x0140) * 0.0625 = 320 * 0.0625 = 20.0°C 。

3.2 LED控制：GPIO输出与状态同步

LED控制看似简单，却是验证下行指令通路的关键。设计上需实现硬件驱动与软件状态的严格同步：
- 硬件连接 ：LED阳极接3.3V，阴极经限流电阻（220Ω）接STM32的GPIOA_Pin5。此为低电平有效设计， HAL_GPIO_WritePin(GPIOA, GPIO_PIN_5, GPIO_PIN_SET) 熄灭LED， GPIO_PIN_RESET 点亮LED。
- 状态变量 ：在全局定义 uint8_t led_status = 0; ，初始值为0（熄灭）。所有LED操作必须通过修改此变量并调用统一函数 led_set_state(uint8_t state) 执行，禁止在多处直接调用HAL函数，以防状态不一致。
- 指令解析逻辑 ：在USART2中断服务函数（ USART2_IRQHandler ）中，当接收到完整一帧JSON数据后，调用CJSON库解析。若 cJSON_GetObjectItemCaseSensitive(root, "led") 返回非NULL且其值为1，则执行 led_set_state(1) ；若为0，则执行 led_set_state(0) 。解析失败时，保持原状态不变，不执行任何动作。

3.3 USART2通信：中断驱动与环形缓冲区设计

USART2是STM32与ESP-01S的唯一数据通道，必须采用中断方式实现全双工、零丢包通信。轮询方式在高频率数据交互下会严重阻塞主循环，无法及时响应温度采集或LED控制事件。

3.3.1 环形缓冲区（Ring Buffer）实现

为避免中断服务函数中执行耗时操作（如JSON解析），采用生产者-消费者模型：
- 生产者（中断服务函数） ： USART2_IRQHandler 中，每接收到一个字节，将其存入 rx_buffer[rx_write_index] ，然后 rx_write_index = (rx_write_index + 1) % RX_BUFFER_SIZE 。若缓冲区满，则丢弃新字节并置位 rx_overflow_flag （用于调试）。
- 消费者（主循环） ：在 while(1) 中，检查 rx_read_index != rx_write_index ，若成立，则从 rx_buffer[rx_read_index] 读取字节，解析JSON。解析完成后， rx_read_index = (rx_read_index + 1) % RX_BUFFER_SIZE 。

缓冲区大小需权衡：过小（如64字节）易溢出；过大（如2048字节）则浪费RAM。本方案选用512字节，可容纳约3条完整JSON消息（含换行符）。

3.3.2 波特率与时钟配置依据

USART2挂载于APB1总线，STM32F103C8T6的APB1最大频率为36MHz。配置USART2_BRR寄存器时，需确保波特率误差≤±3%。以9600波特率为例：
- USARTDIV = (36000000 / (16 * 9600)) = 234.375
- 取整数部分234（0xEA），小数部分0.375（0x6）写入BRR[3:0]，最终BRR = 0xEA6。
- 实际波特率 = 36000000 / (16 * (234 + 0.375)) = 9600.00，误差为0，完全满足要求。

若误将APB1时钟配置为72MHz（超出规格），则 USARTDIV 计算错误，导致波特率偏差超标，表现为ESP-01S接收乱码。

4. ESP-01S固件开发与AT指令集深度应用

ESP-01S作为网络接入层，其固件开发本质是对乐鑫官方AT固件的定制化调用。理解AT指令的时序、状态机与错误码含义，是打通云管端链路的基石。本节摒弃“AT指令列表式罗列”，聚焦于工程实践中最易踩坑的四个核心指令及其上下文逻辑。

4.1 AT+CWMODE_CUR：WiFi工作模式的隐含约束

AT+CWMODE_CUR=1 将ESP-01S设置为Station模式，这是连接手机热点的前提。但该指令生效有严格前提：
- 必须在AT+RST复位后首次执行 ：若ESP-01S已处于SoftAP模式（如之前配置过 AT+CWMODE=2 ），直接发送 AT+CWMODE_CUR=1 将返回 ERROR 。正确流程是：先 AT+RST 硬复位，待模块返回 ready 后，再发送 AT+CWMODE_CUR=1 。
- 与AT+CWMODE_DEF的区别 ： _CUR 仅修改当前会话模式，断电后失效； _DEF 则写入Flash，下次上电自动生效。调试阶段应始终使用 _CUR ，避免因Flash写入失败导致模块“变砖”。曾有案例因误用 AT+CWMODE_DEF=1 后模块无法启动，最终需通过GPIO0接地强制进入Flash下载模式恢复。

4.2 AT+CWJAP_CUR：连接热点的超时与重试策略

AT+CWJAP_CUR="SSID","PASSWORD" 是连接手机热点的关键指令。其行为远比表面复杂：
- 超时机制 ：模块内部有固定连接超时（约20秒）。若手机热点信号弱或密码错误，模块将返回 FAIL 而非 ERROR 。 FAIL 表示连接尝试失败，但模块仍处于正常AT指令状态； ERROR 则表示指令语法错误或模块异常。
- 重试逻辑 ：不能在收到 FAIL 后立即重发 AT+CWJAP_CUR 。必须等待模块主动返回 WIFI DISCONNECT 或 WIFI GOT IP ，才能发送下一条指令。强行重发将导致模块进入未知状态，需 AT+RST 恢复。工程实践中，应在主循环中轮询 AT+CIPSTATUS ，当返回 STATUS:2 （已连接）或 STATUS:5 （获取IP）时，才认为连接成功。
- 信号强度判断 ： AT+CWJAP_CUR 成功后，立即执行 AT+CWJAP? 可返回当前连接的SSID与信号强度（RSSI）。RSSI值>-70dBm为良好，<-85dBm则数据传输易丢包。若RSSI过低，应提示用户调整手机位置，而非盲目重连。

4.3 AT+CIPSTART与AT+CIPSEND：MQTT连接的三次握手本质

阿里云IoT要求设备通过MQTT协议接入，而ESP-01S AT固件将MQTT抽象为TCP连接。 AT+CIPSTART 与 AT+CIPSEND 的组合，实则是MQTT CONNECT与PUBLISH报文的手动构造：

4.3.1 AT+CIPSTART：建立TCP隧道

AT+CIPSTART="TCP","iot-as-mqtt.cn-shanghai.aliyuncs.com",1883 指令并非简单建立连接，而是触发ESP-01S内部的TLS握手（若启用SSL）与域名解析。关键点：
- 域名解析失败 ：若返回 DNS Fail ，表明模块DNS服务器（通常为 114.114.114.114 ）不可达。此时应检查WiFi连接是否真正成功（ AT+CWLIF 查看已连接设备列表），而非仅看 AT+CWJAP_CUR 返回 OK 。
- 连接状态确认 ：成功后返回 Linked ，但此时仅TCP连接建立，尚未进行MQTT协议交互。必须在此之后发送MQTT CONNECT报文。

4.3.2 AT+CIPSEND：手动构造MQTT CONNECT报文

MQTT CONNECT报文是二进制数据，需按协议规范逐字节构造。一个典型的CONNECT报文（不含用户名密码）结构如下：

0x10, 0xXX, // 固定报头：类型(CONNECT)=0x10，剩余长度（需动态计算）
0x00, 0x04, 'M', 'Q', 'T', 'T', // 协议名
0x04, // 协议级别
0xD2, // 连接标志（Clean Session=1, Will Flag=0, Will QoS=0, Will Retain=0, Password Flag=0, User Name Flag=0）
0x00, 0x3C, // 保活时间（60秒）
0x00, 0x0A, 'd', 'e', 'v', 'i', 'c', 'e', '_', 'i', 'd' // 客户端ID

0xXX 处的剩余长度需根据后续字段总长度计算。若计算错误，阿里云服务器将立即关闭连接，返回 CLOSED 。工程中应编写辅助函数自动计算并填充。

4.4 AT+CIPRECVDATA：接收下行指令的字符流解析陷阱

AT+CIPRECVDATA 用于接收云端下发的MQTT消息，但其返回格式极易引发解析错误：
- 返回格式 ： +IPD,<length>:<data> ，其中 <length> 为十六进制字符串， <data> 为原始字节流。例如， +IPD,15:{"led":1} 。
- 常见陷阱 ：
- length 字段后紧跟冒号 : ，若解析时未跳过，会将 : 误认为JSON首字符，导致cJSON_Parse失败。
- data 部分可能包含不可见字符（如 \r\n ），若JSON解析库未忽略空白符，将返回 Invalid value 错误。
- 一次 AT+CIPRECVDATA 可能返回多条消息（若云端批量推送），或一条消息被拆分为多次返回。必须在应用层实现消息边界识别，通常以 } 为结束符，累积接收直到遇到完整JSON对象。

5. 阿里云IoT平台配置与设备影子实践

阿里云IoT平台是系统的云端大脑，其配置质量直接决定设备能否被正确识别、数据能否被准确解析、指令能否被及时送达。本节直击配置中最易被忽视的三个技术细节：Product Key与Device Name的绑定逻辑、Topic权限的最小化原则、设备影子（Device Shadow）的原子性更新机制。

5.1 Product Key与Device Name：设备身份的唯一性保障

在阿里云IoT控制台创建产品时，系统自动生成Product Key（如 a1B2c3D4e5F ）。添加设备时，需手动输入Device Name（如 stm32_esp_led_001 ）。二者共同构成设备的全球唯一标识（IOT ID），其绑定关系具有强约束性：
- 不可更改性 ：Device Name一旦创建，终身不可修改。若需更换名称，必须删除设备并重新添加，但此举将丢失该设备的历史数据与规则引擎配置。因此，Device Name应遵循“项目名_功能_序列号”规范（如 agri_temp_monitor_001 ），避免使用 test 、 demo 等临时性命名。
- 密钥派生 ：设备连接MQTT时，用户名为 DeviceName&ProductKey ，密码为 hmacsha1(ProductSecret, DeviceName+ProductKey+TimeStamp) 。若Product Secret泄露，攻击者可伪造任意设备身份。因此，Product Secret必须严格保密，禁止硬编码在固件中。工程中应将Product Secret存储于STM32的Option Bytes（通过 HAL_FLASHEx_OptionBytesProgram 写入），利用芯片硬件加密特性保护。

5.2 Topic配置：遵循最小权限原则

阿里云IoT为每个设备预置三个系统Topic：
- $sys/{productKey}/{deviceName}/thing/event/property/post ：设备上报属性（如温度）。
- $sys/{productKey}/{deviceName}/thing/service/property/set ：云端下发属性设置指令（如LED开关）。
- $sys/{productKey}/{deviceName}/thing/event/property/post_reply ：云端对上报的ACK。

关键配置项 ：在产品Topic类定义中，必须将 /thing/event/property/post 的权限设置为 发布（Publish） ，将 /thing/service/property/set 的权限设置为 订阅（Subscribe） 。若错误地将后者也设为Publish，则设备可向该Topic发布消息，但云端不会处理，造成指令石沉大海。反之，若前者设为Subscribe，设备将无法上报数据。

5.3 设备影子（Device Shadow）：实现状态同步的原子操作

设备影子是阿里云IoT提供的JSON文档，用于存储设备的期望状态（desired）与报告状态（reported），解决设备离线时指令丢失问题。其核心价值在于“最终一致性”：
- 期望状态（desired） ：用户在控制台点击“LED ON”时，平台将 {"state":{"desired":{"led":1}}} 写入影子。
- 报告状态（reported） ：设备上线后，主动读取影子，获取 desired.led 值并执行，然后将执行结果写回 {"state":{"reported":{"led":1}}} 。
- 原子性保证 ：影子更新是原子操作。若设备同时收到两条指令（如 desired.led=1 和 desired.led=0 ），平台会按时间戳覆盖，最终只保留最新值。设备无需处理指令队列，只需定期同步影子即可。

在固件中实现影子同步，需在MQTT连接成功后，首先订阅 $aws/things/{deviceName}/shadow/update/accepted ，然后发送GET请求至 $aws/things/{deviceName}/shadow 。收到影子文档后，解析 state.desired 字段，执行相应操作，并立即发布 state.reported 更新。此过程必须幂等——重复执行同一 desired 值不应产生副作用。

6. 分阶段调试方法论与典型故障排查

一个健壮的物联网系统，其调试过程本身就是对系统理解的深化。本方案严格遵循“分层隔离、逐段验证、工具佐证”的十二字方针，将复杂系统拆解为三个可独立验证的阶段，并为每个阶段提供精准的故障定位手段。

6.1 阶段一：STM32 ↔ ESP-01S UART通信验证

目标 ：确认两者间串口数据收发100%可靠，无丢包、无错帧。
验证方法 ：
- 硬件环回测试 ：将ESP-01S的TX与RX引脚短接，STM32通过 HAL_UART_Transmit 发送 "AT\r\n" ，然后调用 HAL_UART_Receive 接收。若收到 "OK\r\n" ，证明STM32的USART2硬件与驱动无问题。
- ESP-01S透传模式 ：给ESP-01S烧录透传固件（如 esp_init_data_default.bin ），使其成为纯粹的串口-网络桥接器。PC端串口助手发送 "Hello ESP" ，应能在ESP-01S的TX引脚用示波器捕获到相同ASCII码流。
- 关键指标 ：使用逻辑分析仪抓取USART2的TX/RX波形，测量波特率误差（应≤±3%）、起始位宽度（应≈104μs @9600bps）、数据位采样点（应在位宽50%处）。

典型故障 ：
- 现象 ：STM32发送 AT ，ESP-01S无响应。
- 排查链 ：① 万用表测ESP-01S VCC是否为3.3V；② 示波器查STM32 TX引脚是否有波形；③ 若有波形，查ESP-01S RX引脚是否接收到相同波形；④ 若RX无波形，检查连接线是否虚焊；⑤ 若RX有波形但ESP无响应，用USB转TTL模块直连ESP-01S，确认其AT固件完好。

6.2 阶段二：ESP-01S ↔ 阿里云MQTT连接验证

目标 ：确保ESP-01S能稳定连接阿里云，收发MQTT消息。
验证方法 ：
- AT指令白盒测试 ：使用USB转TTL模块，按顺序执行：
AT+CWMODE_CUR=1 AT+CWJAP_CUR="MyHotspot","12345678" AT+CIPSTART="TCP","iot-as-mqtt.cn-shanghai.aliyuncs.com",1883 AT+CIPSEND=xx [发送MQTT CONNECT报文]
每步观察返回值，记录 OK 、 FAIL 、 ERROR 、 CLOSED 的具体含义。
- 云端日志追踪 ：在阿里云IoT控制台的“设备管理 > 日志服务”中，开启设备日志。当ESP-01S发送CONNECT报文后，日志中应出现 MQTT connect success ；发送PUBLISH后，应出现 Message received on topic ... 。

典型故障 ：
- 现象 ： AT+CIPSTART 返回 DNS Fail 。
- 根因 ：手机热点未开启DHCP，或ESP-01S获取到的DNS服务器地址（如 192.168.43.1 ）无法解析域名。
- 解决方案 ：在 AT+CWJAP_CUR 成功后，立即执行 AT+CIPDNS_DEF=1,"114.114.114.114" ，强制指定公共DNS。

6.3 阶段三：全链路功能联调与性能优化

目标 ：温度数据稳定上报，LED指令即时响应，系统长期运行无内存泄漏。
验证方法 ：
- 压力测试 ：在STM32端设置定时器，每5秒触发一次温度采集与上报。连续运行24小时，监控阿里云控制台数据点是否连续，无缺失。
- 指令时延测量 ：在阿里云控制台点击“LED ON”，用示波器探头接触STM32的GPIOA_Pin5，测量从点击到LED电平翻转的时间。合格标准：< 1.5秒（WiFi连接+MQTT传输+JSON解析+GPIO操作）。
- 内存泄漏检测 ：在ESP-01S固件中，每次 malloc 后记录指针， free 后清除。若运行数小时后 heap_caps_get_free_size(MALLOC_CAP_8BIT) 持续下降，则存在泄漏。

性能优化点 ：
- JSON序列化 ：避免在中断中调用 cJSON_Print （内存分配开销大）。改用预分配缓冲区+手动拼接，如 snprintf(json_buf, sizeof(json_buf), "{\"temperature\":%.2f}", temp); 。
- MQTT心跳 ： AT+CIPKEEPALIVE 设置保活时间为60秒，低于阿里云默认的300秒，可更快发现网络中断。
- 低功耗设计 ：当无数据上报时，STM32进入Stop模式，由USART2的IDLE中断唤醒，降低整机功耗至2mA以下。

我在实际项目中曾遭遇一个诡异故障：系统运行数小时后，ESP-01S突然无法连接WiFi， AT+CWJAP_CUR 始终返回 FAIL 。排查数日无果，最终发现是手机热点在无流量时自动进入节能模式，关闭了Beacon帧广播，导致ESP-01S扫描不到SSID。解决方案是将手机热点设置为“始终在线”，或改用路由器作为AP。这个教训印证了一个真理：物联网调试，永远要怀疑最底层的基础设施。