做嵌入式难免要跟WiFi打交道。我之前做一块采集板的时候，MCU 要把传感器数据送到远端服务器，一开始走有线，工程现场布线太痛苦，换成一对无线串口模块又发现传输不可靠、误码率高。后来换成 ESP-12F 做 WiFi 数据透传，串口侧照常收发，网络侧由模块自己搞定 TCP 连接，整个思路一下子就顺了。这篇就把从选型、连接、AT 指令配置到源码级实现的全过程整理出来，给准备在项目里用 ESP-12F 做透传的朋友当一份参考。
1. 透传到底在传什么：先看懂 WiFi 透传的三个环节
1.1 透传的本质是“替 MCU 搬家”
WiFi 数据透传，说白了就是让模块承担从串口到网络的搬运工作。MCU 不需要懂 TCP/IP，也不需要知道路由器密码怎么配置，它只要往 UART 写字节，ESP-12F 就把这些字节打包成 TCP 数据发出去；反过来，服务器发来的数据，模块拆包后从 UART 吐出来。对 MCU 来说，ESP-12F 是一个“无线串口”，对外接口只有 TX、RX、电源和地。
这里要强调一个容易想偏的点：WiFi 透传不是简单地把串口的电平转成无线信号，中间必然要经过 TCP/UDP 协议封装。也就是说，你串口发的一帧数据到了服务器那边，可能被拆成几个 TCP 段，也可能几个串口帧被拼在一个段里。所以“透传”透的是应用层的数据流，不是逐字节的时序。搞明白这点，后面设计缓冲区和解析逻辑就不会钻牛角尖。
1.2 ESP-12F 在链路中的位置
一条完整的透传链路有三方：
- 数据源：MCU 或传感器，通过串口把数据交给 ESP-12F；
- 中转站：ESP-12F 模块，负责连接无线路由器、建立 TCP 连接、双向搬运数据；
- 终点：服务器或上位机，监听端口，接收和处理数据。
实际项目里，数据源这一侧往往也是系统的控制核心，所以 ESP-12F 大多数时候是“配角”，但恰恰是配角决定了链路稳不稳定。我见过不少项目，MCU 程序写得很漂亮，最后卡在模块上电连不上网、连上网几小时掉线、数据丢包这些问题上。这些坑多半不是代码逻辑错，而是对模块工作方式和供电环境理解不够。
1.3 两种角色，两种玩法
ESP-12F 有两种截然不同的用法：
- AT 指令模块模式：模块里烧录官方 AT 固件，由外部 MCU 通过串口发送 AT 指令控制。MCU 资源充足时用这种，开发快，逻辑清晰。
- 独立主控模式：直接用 ESP-12F 的 ESP8266EX 芯片当主控，基于 SDK 写自己的程序，把 WiFi 协议栈和业务逻辑放在同一个芯片里。适用于功能简单、想省掉一颗 MCU 的场景。
这篇文章先重点讲 AT 指令透传，因为它的应用面更广，也更容易被大家接受。后面单独开一节讲独立主控方案的关键区别，方便你按项目情况二选一。
2. 模块选型和硬件连接：透传不稳，多半是电和地没伺候好
2.1 ESP-12F 和 ESP-01S 怎么选
ESP-12F 是 ESP8266 系列里很经典的封装，板载 PCB 天线，引出所有可用 GPIO，Flash 容量一般做到 4MB，模块自带屏蔽罩。相比 ESP-01S，它最大的优势是引脚多、Flash 大、信号质量好。
我自己做透传产品，默认推荐 ESP-12F，除非空间实在紧张才考虑 ESP-01S。两者关键差异如下：
| 项目 | ESP-01S | ESP-12F |
|---|---|---|
| Flash 容量 | 1MB 常见 | 4MB 常见 |
| 可用 GPIO | 2 个左右 | 全部引出 |
| 天线 | PCB 或外置 | PCB，可选 IPEX |
| 屏蔽罩 | 部分版本无 | 有 |
| 串口引出 | 占用 GPIO1/GPIO3 | 独立或复用 |
| 适合场景 | 纯透传、空间极小 | 透传+少量控制、复杂逻辑 |
如果你只需要纯透传，ESP-01S 也能用，但它的串口和 Flash 下载引脚冲突，调试时容易反复插拔，体验差不少。ESP-12F 的 UART0 RX/TX 也承担下载功能，只是因为它 GPIO 多，你可以把复位和 GPIO0 引出来做一键下载，整体从容很多。
2.2 供电是透传的第一道生死线
WiFi 模块发射瞬间电流能冲到 300mA 以上，平均电流也在 70~90mA 左右。如果供电端扛不住这个脉冲，模块表现就是“上电能跑，一连 WiFi 就重启”，或者“连上路由器但 GOT IP 很慢”。
我的建议：
- 使用 3.3V 输出能力不低于 500mA 的 LDO，比如常见的 AMS1117-3.3 在输入输出压差合适时可以，但要注意它在高频瞬态响应上偏慢，最好再并联电容；
- 模块电源引脚附近放一个 100uF 电解电容和一个 0.1uF 陶瓷电容；
- 如果模块和其他数字电路共用一个 3.3V，务必在模块附近再放一级储能电容，而不是只在电源入口放；
- 不要用二极管做防反接串联，二极管的压降会让 3.3V 变成 2.9V 甚至更低，WiFi 发射时模块极可能掉电复位。
实测中我遇到过：某批次板子用的是 USB 供电，线缆电阻大，模块一连接路由器就复位，串口打印全乱。后来在模块的 VCC 和 GND 之间补了一个 470uF 电容，问题消失。这个看起来不起眼的电容，往往是稳定性的关键。
2.3 电平匹配和引脚处理
ESP-12F 的 IO 电平是 3.3V，不兼容 5V。如果 MCU 是 5V，那 MCU 的 TX 到模块 RX 之间必须分压，最简单的做法是串一个 1kΩ 和 2kΩ 电阻分压，把 5V 降到 3.3V 左右。模块 TX 到 MCU RX 的方向，因为模块输出 3.3V，大部分 5V MCU 能识别高电平，但还是建议串一个 330Ω 电阻做保护，避免模块 GPIO 在下载时和 MCU 串口打架。
还有一个很容易漏掉的问题：模块的 EN（也叫 CH_PD）引脚必须接上拉电阻到 3.3V，否则模块可能处于复位状态。GPIO0 在运行时必须悬空或接高，下载固件时拉低再上电。很多人在原理图上把 GPIO0 悬空，实际使用没问题，但如果你用 JTAG 或者在线调试时误拉低，模块就进下载模式，表现出来是串口无响应，容易被误判成模块坏了。
2.4 串口参数和共地
模块默认 AT 固件的串口参数通常是 115200 8N1，但有些出厂版本是 9600，建议上电后先发一个“AT”确认，如果返回 OK 再继续。无论波特率多少，MCU 的 GND 必须和模块的 GND 连在一起，否则串口通信会出现随机乱码。这个低级问题在接线调试时非常常见：USB 转串口的地和模块的地各接各的，结果电脑端收一堆乱码。
3. 把 AT 指令透传跑通：配置顺序和网络拓扑选择
3.1 先想清楚用哪种网络角色
AT 指令版本支持三种常见透传拓扑：
- TCP Client 模式：模块主动去连服务器。适合大多数 M2M 场景，部署简单，服务器只需要一个监听端口。
- TCP Server 模式：模块开一个端口等待连接。适合局域网内的临时调试，手机或电脑主动连模块。但这种模式下模块最多允许一个客户端连接（CIPMUX=0 时），Active Over Time 一长也会断。
- UDP 透传模式：模块和远端 IP:端口 绑定，无连接，收发不保证可靠。适合实时性要求高、丢包容忍度高的音视频或控制类数据。
我做设备上云，首推 TCP Client。原因很简单：设备端 DHCP 拿到地址后主动外连，不需要在路由器上做端口映射，服务器公网 IP 一变，设备端只需要改一次配置。
3.2 核心 AT 命令序列
以下是 TCP Client 透传的标准流程：
AT // 测试模块是否响应 AT+CWMODE=1 // 设置为 Station 模式 AT+CWJAP="MyWiFi","12345678" // 连接无线路由器 AT+CIPMUX=0 // 单连接模式 AT+CIPSTART="TCP","192.168.1.100",8080 // 建立 TCP 连接 AT+CIPMODE=1 // 开启透传模式 AT+CIPSEND // 进入发送状态，返回 > 后进入透传执行完最后一条指令，串口会返回一个大于号>，之后就进入了“所见即所发”的状态：你从 MCU 串口写入的每个字节，都会被模块直接通过 TCP 连接发往服务器。服务器发来的数据，模块也会原样从串口吐出。
3.3 域名、隐藏 SSID 和参数细节
如果服务器地址是域名，AT+CIPSTART可以直接写域名，模块内部会走 DNS 解析：
AT+CIPSTART="TCP","iot.example.com",8080这里有几个坑：
- 域名不要带
http://或https://前缀； - SSID 或密码里如果含特殊字符，要用转义形式，不同固件处理方式略有差异，最简单的办法是换一个不含特殊字符的测试 AP；
- 连接隐藏 SSID 时，
AT+CWJAP不一定有效，部分固件会一直报CONNECT FAIL。如果必须用隐藏 WiFi，建议改用AT+CWJAP加 BSSID 参数的指令格式，或者先在路由器上把 SSID 广播打开，连上后再隐藏； AT+CWJAP返回WIFI CONNECTED和WIFI GOT IP表示成功，只返回WIFI CONNECTED但迟迟没有GOT IP，说明 DHCP 阶段失败，需要检查路由器的地址池或手动配置静态 IP。
3.4 退出透传：不要迷信“+++”
透传模式下，模块不再解析 AT 指令，想退出透传有几种办法：
发送“+++”，要求前后各至少 1 秒没有任何串口数据。这个时序很苛刻，MCU 端如果一直有数据流，很难掐准窗口。而且部分非官方固件根本不支持“+++”退出。
更稳的办法：
- 远端主动断开 TCP 连接，模块会自动退出透传，此时串口会输出
CLOSED； - 如果 MCU 有控制引脚，可以拉低 EN 再拉高，强制模块重启，代价是重新走一遍联网流程；
- 在设计初期就把“退出透传”当成一个远程指令来处理：服务器下发特定业务报文，MCU 收到后不再发送“+++”，而是直接重启模块或切到非透传模式。
我建议的兜底策略是：定期让服务器主动断开空闲连接，或者 MCU 检测到通信中断就重启模块。这样即使透传状态异常，系统也能自愈，不用依赖“+++”的完美时序。
4. MCU 端透传源码设计：状态机、缓冲区、断线重连
4.1 软件总体架构
MCU 端透传程序不能只会“发两个 AT 指令、然后死循环转发”，因为系统要处理配置、超时、断线、心跳，还要避免把 AT 响应误当业务数据。我常用的架构分四层：
- 串口驱动层：负责字节收发，中断里写环形缓冲；
- AT 响应解析层：按行解析模块返回的
OK、CONNECT、WIFI GOT IP、CLOSED等事件； - 状态管理层：维护联网状态机，处理重试和超时；
- 应用数据通路：透传模式下，串口字节直接进业务缓冲区，不走 AT 解析。
下面用一个简化版 C 代码骨架演示，实际工程在此基础上加内存池、日志等。
4.2 状态机定义
typedef enum { T_STATE_IDLE, T_STATE_CONNECT_WIFI, T_STATE_WAIT_GOT_IP, T_STATE_CONNECT_TCP, T_STATE_ENTER_TRANSPARENT, T_STATE_TRANSPARENT, T_STATE_RECONNECT_DELAY } t_state_t; static t_state_t g_state = T_STATE_IDLE; static uint32_t g_state_timeout = 0;状态迁移原则是：每一步都有超时，超时后回到T_STATE_RECONNECT_DELAY，延迟一段时间后重新开始。否则模块一旦卡在某个中间状态，整个链路就瘫痪了。
void transparent_task(void) { switch (g_state) { case T_STATE_IDLE: at_send_cmd("AT\r\n"); g_state = T_STATE_CONNECT_WIFI; g_state_timeout = tick_now() + 5000; break; case T_STATE_CONNECT_WIFI: if (at_has_ack("OK")) { at_send_cmd("AT+CWJAP=\"MyWiFi\",\"12345678\"\r\n"); g_state = T_STATE_WAIT_GOT_IP; g_state_timeout = tick_now() + 20000; } break; case T_STATE_WAIT_GOT_IP: if (at_has_ack("WIFI GOT IP")) { at_send_cmd("AT+CIPMUX=0\r\n"); at_send_cmd("AT+CIPSTART=\"TCP\",\"192.168.1.100\",8080\r\n"); g_state = T_STATE_CONNECT_TCP; g_state_timeout = tick_now() + 10000; } break; case T_STATE_CONNECT_TCP: if (at_has_ack("CONNECT")) { at_send_cmd("AT+CIPMODE=1\r\n"); at_send_cmd("AT+CIPSEND\r\n"); g_state = T_STATE_ENTER_TRANSPARENT; g_state_timeout = tick_now() + 5000; } break; case T_STATE_ENTER_TRANSPARENT: if (at_has_ack(">")) { g_state = T_STATE_TRANSPARENT; } break; case T_STATE_TRANSPARENT: // 业务数据的收发都在这个状态处理 break; default: delay_ms(5000); g_state = T_STATE_IDLE; break; } }注意at_has_ack不能简单用strstr匹配"CONNECT"，因为WIFI CONNECTED和CONNECT FAIL也包含这个词。要先读一整行，再做前缀或完全匹配。否则很可能在AT+CWJAP时就误判成 TCP 连接成功。
4.3 串口数据的分流处理
透传模式下，模块返回的>是“准入门槛”。在收到>之前，串口来的一律按 AT 响应处理；收到>之后，串口来的全部算业务数据。我之前见过有人把 AT 响应和业务数据混在一个解析函数里，结果模块一输出CLOSED，业务数据就被吞了。
正确做法是加一个标志位，数据到达时先判断状态：
void uart_rx_callback(uint8_t *data, uint16_t len) { if (g_state == T_STATE_TRANSPARENT) { app_data_pipeline(data, len); } else { at_response_feed(data, len); } }4.4 环形缓冲区设计
透传场景下，串口中断频率不低，如果直接在主循环里逐字节接收，容易丢数据。我建议用环形缓冲：
#define RX_RING_SIZE 1024 static uint8_t rx_ring[RX_RING_SIZE]; static volatile uint16_t rx_head = 0; static volatile uint16_t rx_tail = 0; void uart_isr_byte(uint8_t byte) { uint16_t next = (rx_head + 1) % RX_RING_SIZE; if (next != rx_tail) { rx_ring[rx_head] = byte; rx_head = next; } } uint16_t ring_read(uint8_t *buf, uint16_t max_len) { uint16_t cnt = 0; while (cnt < max_len && rx_tail != rx_head) { buf[cnt++] = rx_ring[rx_tail]; rx_tail = (rx_tail + 1) % RX_RING_SIZE; } return cnt; }缓冲区大小要看业务最大帧。如果单帧超过 1KB，就相应扩大。注意环形缓冲只解决瞬时读写冲突，不解决协议粘包。透传模式下如果你想按帧处理，需要在应用层自己加帧头帧尾或长度字段。
4.5 心跳保活与断线重连
很多服务器会主动断开空闲 TCP 连接，空闲时间有的是 30 秒，有的 5 分钟。设备端不做保活，第二天再去看，连接早就断了。我见过两种保活方案：
- 协议层 TCP KeepAlive：模块 AT 固件不一定开放这个参数，应用层更可靠；
- 应用层心跳：MCU 每隔 N 秒发一个固定报文，比如
#HB#，服务器收到后不回或回一个简单 ACK。
我实测下来，30~60 秒发一次心跳效果不错。但注意心跳和业务数据不要紧挨着发，否则粘包后服务器解析容易出错。如果业务本身就高频，心跳间隔可以放宽到 90 秒甚至取消。
断线检测主要有两种途径：
- 透传模式下模块网络断开，会从串口输出
CLOSED或WIFI DISCONNECT，解析到后应回到重连状态； - 如果模块没输出任何提示，但服务器长时间不回任何数据，应用层需要自己做请求-响应超时判断，超时后主动重启连接。
我倾向两个都做：模块事件是一级检测，应用层业务超时是二级兜底。
4.6 保存透传链路参数
如果你的设备每次上电都要重连同一个服务器，可以用AT+SAVETRANSLINK把连接参数存到 Flash 里，这样下次上电模块会自动连接并进入透传，MCU 少写不少代码：
AT+SAVETRANSLINK=1,"192.168.1.100",8080,"TCP"保存后，模块上电自动进入透传状态。但这种方案的缺点是：参数改起来不方便，而且万一那边服务器 IP 变了，你得先发AT+SAVETRANSLINK=0关掉自动连接才能重新配置。我一般把它用在“现场环境固定、需要快速上电”的场景。
5. 换个思路：直接用 ESP-12F 当主控实现透传
5.1 什么时候可以省掉外部 MCU
如果你的业务很简单——采集几个传感器、控制几个 GPIO、把数据发出去——其实没必要再挂一颗 MCU。ESP8266EX 本身有 80MHz 主频、4MB Flash、几十 KB RAM，跑个简单的数据采集和控制逻辑绰绰有余。这样省下的不仅是一颗芯片的 BOM 成本，还少了一条串口链路，少了一堆 AT 指令状态机代码。
5.2 基于 NONOS SDK 的透传代码逻辑
以官方 NONOS SDK 为例，思路如下：
- 初始化 UART，注册串口接收回调；
- 初始化 WiFi，连接路由器，注册
event回调； - 创建一个
espconn连接，注册recv回调； - 串口收到数据后，通过
espconn_send发送出去； - 收到网络数据后，通过 UART 发送出去。
关键代码骨架大致是：
// 串口接收回调 void uart_rx_cb(char *data, int len) { if (conn && espconn_send(conn, data, len) != ESPCONN_OK) { // 发送失败，需要重连 } } // 网络接收回调 void tcp_recv_cb(void *arg, char *pdata, unsigned short len) { uart_write(pdata, len); } // WiFi 连接事件 void wifi_event_cb(System_Event_t *evt) { switch (evt->event_id) { case EVENT_STAMODE_GOT_IP: espconn_connect(conn); break; } }注意 SDK 模式下，espconn_send是异步的，发送缓冲区满时会返回ESPCONN_OK但数据排队，如果串口数据来的太快，可能直接返回失败。你需要一个发送队列，把没发出去的数据缓存下来，等sent回调里继续发。这个队列和环形缓冲类似，但要注意内存上限，避免堆积过多导致内存耗尽。
5.3 AT 方案和 SDK 方案怎么选
| 对比项 | AT 指令透传 | SDK 直接透传 |
|---|---|---|
| 开发难度 | 低，串口操作即可 | 中，需要理解 SDK 事件模型 |
| 额外 MCU | 需要 | 不需要 |
| 灵活性 | 受 AT 固件限制 | 高，可自由定义协议 |
| 数据延迟 | 有 AT 解析和转发开销 | 较低 |
| 稳定性 | 依赖固件，断线处理间接 | 可完全自控 |
| 适用场景 | 快速开发、已有 MCU | 低成本、简洁硬件 |
曾经有一个项目，最初用 STM32 + ESP-12F AT 方案，后因为成本压得紧，把 STM32 的功能精简后全部移植到 ESP-12F 上，板子面积小了近三分之一。代价是原先用 CUBE 生成的驱动都要重写，工作量比预期大。所以选型时不只是比 BOM 成本，也要把人力成本算进去。
6. 实测数据和坑位清单：透传调试中踩过的那些雷
6.1 实测吞吐量
先给一组我自己测试的数据，环境是 ESP-12F 模块连手机热点，手机热点带宽大约 40Mbps，服务器在同一局域网内，UART 波特率 115200：
| 传输方向 | 数据流 | 实测吞吐 |
|---|---|---|
| 串口->WiFi | 每包 64 字节，间隔 10ms | 约 6.4KB/s |
| 串口->WiFi | 每包 512 字节，连续发送 | 约 10KB/s |
| WiFi->串口 | 服务器连续发送 | 约 9KB/s |
在 115200 波特率下，串口理论极限是 11.5KB/s，所以瓶颈完全在 UART。如果想提升上行速度，就把波特率提到 460800 或 921600，这时候线材质量和供电纹波对误码率的影响会变得非常明显，建议用短线并保证地线最短。
有一点要注意：AT 透传模式下数据从串口到达再到 TCP 发出，模块内部会有缓存和组包逻辑，你从服务器看数据，可能不是串口逐字节到达的，而是攒了几十毫秒后一次性出来。实时性要求高的场景，建议关闭透传模式，改用AT+CIPSEND=<length>主动发包，虽然多几步 AT 交互，但每一包数据的延迟可预期。
6.2 雷区一：模块反复重启
现象：上电串口有输出，但执行到AT+CWJAP时模块重启，串口重新打印 boot 信息。
原因几乎都是供电。WiFi 发射瞬间电流大，如果供电线路阻抗高或者 LDO 余量小，模块电压瞬间跌落，触发欠压复位。对策就是前面说的电容阵和独立供电。另外一个隐蔽原因是：调试时用的 USB 转串口模块本身供电能力弱，模块直接从 USB 转串口的 3.3V 取电，一发射就掉电。老老实实给模块单独供 3.3V，只和 USB 转串口共地。
6.3 雷区二：串口数据粘包和丢包
透传模式下，MCU 如果频繁调用uart_write发送很小的包，模块可能把这些小包合并成一个 TCP 段发出。服务器如果按长度拆包，就会把两个业务帧读成一个帧。
两种解法：
- 发送端在每帧后面加一个帧尾，比如
\r\n，服务器按帧尾切分数据； - 接收端用定长格式，每帧带长度头，比如 2 字节长度 + 数据。这是更稳的方案，尤其适合二进制协议。
丢包则要先区分是串口丢还是网络丢。串口丢一般是因为 MCU 主循环读缓冲不及时，缓冲被覆盖。网络丢可能是路由器信号差或 TCP 重传延迟。排查时先把波特率降到 9600 试试，如果低波特率不丢、高波特率丢，基本锁定是线材或电平问题，而不是模块本身。
6.4 雷区三：透传模式退出失败
前面提到过“+++”的时序问题。在实际项目里，我曾经让 MCU 一直以 2 秒间隔发心跳，结果想用“+++”退出透传时，因为模块无法识别到底哪个“+++”是退出序列，一直没能退出。最后是在服务器端先把连接杀掉，模块收到CLOSED后自动退出透传，才恢复正常控制。
从此我定下一个规矩：**生产固件不指望“+++”退出透传，要么靠掉线自动退出，要么靠远程指令触发重启。**调试阶段倒是无所谓，毕竟有电脑看着。
6.5 雷区四：上电后 DHCP 太慢
有些路由器 DHCP 响应慢，模块AT+CWJAP返回WIFI CONNECTED后，要等十几秒才返回GOT IP。如果你在状态机里把等待时间设成 5 秒，就会超时误判。
解决思路：
- 等待时间放长到 20 秒以上；
- 或者给模块配置静态 IP，用
AT+CWDHCP=0,0关闭 DHCP，然后用AT+CIPSTA设置地址。静态 IP 不仅启动快，还能避免现场路由器 DHCP 租约变化导致的断网，但换环境时配置要跟着改。
我这个项目里，生产固件用 DHCP + 20 秒超时，测试固件用静态 IP，两者各有用途。
6.6 雷区五：串口调试工具的隐藏干扰
硬件调试时我发现一个诡异现象：用某款 USB 转串口工具打开串口，模块就会自动复位。查了半天发现是调试工具的 DTR 和 RTS 信号在打开串口时会翻转，恰好连到了模块的 GPIO0 和 EN 上。如果你把模块直接插在带控制信号的串口座上，务必检查 DTR/RTS 是不是被系统自动拉低。
对策很简单：要么把 DTR/RTS 悬空，要么在软件上关闭 DTR/RTS 控制。这个坑在裸模块调试阶段最常遇到，明明接线看起来没问题，模块却反复重启。
6.7 雷区六：服务器和模块的 TCP 分节缓冲
TCP 本身是流协议，没有消息边界。哪怕模块不做任何合并，路由器、系统协议栈也可能重组数据。很多新手写服务器端代码时，直接recv然后按一包处理，结果数据不完整。
我的习惯是服务器端维护一个接收缓冲，先收进缓冲，再按协议帧的帧头长度字段切帧。这和模块端粘包处理是对称的，两边都按“数据流 + 帧协议”来做，就不会有边界问题。
写在最后：我的工程习惯
做了几个透传项目之后，我总结出一套自己的调试顺序：先把硬件供电搞定，再用串口助手手动调通 AT 指令流程，确定模块能稳定进入透传，最后才写 MCU 的状态机代码。很多人一上来就写代码，出了问题既要排查代码又要排查硬件，效率很低。
另外，如果你手头有开发板，建议一次买两个模块，一个接电脑调试，一个接 MCU 测试。备用模块的价值在踩坑时会体会得很深。这个小习惯，让我少熬了好几个通宵。
