1. 从机测试到底在测什么先把边界划清楚做蓝牙模块的从机测试最容易走的弯路是拿主机的那套思路来套——打开手机搜一搜、连上发两个字符串、能收到回显就收工。这种测法只能证明今天这颗模块没坏证明不了任何工程问题。我前几年做过一批带蓝牙从机的设备出厂前用这套流程全测通过结果客户现场一屋子设备同时上电配对的、连不上的、连上就断的问题全冒出来了。先把概念捋顺。蓝牙模块的从机Slave / Peripheral指的是等待别人发起连接的那一端。在经典蓝牙BR/EDR也就是常说的 SPP 串口透传里从机负责广播自己的名字和地址主机来发起配对在低功耗蓝牙BLE里从机叫 Peripheral靠广播包Advertising宣告存在主机Central来发起连接。HC-05、HC-06、JDY-31 这类属于经典蓝牙 SPP 模块HM-10、JDY-08、部分 CC2541 方案属于 BLE 模块。两者在测试方法上有相当多的差异不能混着来。从机测试的核心目标说到底就四件事它对不对AT 配置和参数能否正确写入和读回、别人找不找得到它广播与可发现性、连上之后稳不稳配对、连接参数、断连重连、数据走不走得通透传正确性、吞吐、延迟。这里有个很多人忽略的点从机测试有两个视角。一个是模块视角把模块当独立被测对象看它的射频、协议栈、外设行为另一个是系统视角把模块当整机的一部分测 MCU 与模块之间的串口时序、电源纹波、结构屏蔽对天线的影响。绝大多数现场问题出在第二个视角上而绝大多数教程只讲第一个视角。我一般会在测试计划里明确写一句从机测试不追求把模块测坏而是要在尽可能短的时间里复现真实使用场景下最可能出问题的边界条件。举个具体例子。HC-06 这种老模块很多人测的时候直接接 USB-TTL 板子波特率 9600 一路通畅。但装到设备上以后MCU 的串口在初始化时会输出一段调试日志波特率还跟模块不一样 —— 这段乱码会被模块当成指令流解析运气不好就把模块带进了莫名其妙的模式。这不是模块的锅是测试环境没模拟真实场景。所以从机测试一定要包含上电时序测试这一项先给谁上电、串口线什么时候拉高、有没有上拉电阻、EN/KEY 引脚在上电瞬间的电平状态都要按最终产品的实际电路来复现。适合读这篇内容的人大概三类做硬件选型和板级调试的工程师、做嵌入式固件要和蓝牙模块串口打交道的开发者、以及做产品测试和出厂检测的朋友。不需要你精通射频但至少要会用串口助手、能看懂 AT 指令表、知道万用表怎么量电压。2. 测试环境与模块选型工具不对白干半天2.1 从机模块横向对比与选型思路先说选型因为很多人是从手上有什么就用什么开始的结果后面踩了一堆本可以避免的坑。下面这张表是我这几年实际用过的几款从机模块的横向对比参数以常见批次为准不同厂家会有差异采购前记得跟供应商要最新规格书。模块型号蓝牙类型默认串口波特率AT 模式波特率供电范围默认配对码典型场景HC-05经典蓝牙 SPP960038400多数版本3.6V~6V1234主从可切换、透传HC-06经典蓝牙 SPP960096003.6V~6V1234纯从机、低成本JDY-31经典蓝牙 SPP960096003.3V~5V1234兼容 HC-06 指令HM-10BLE 4.0960096003.3V~5V无BLE 不强制手机互联、低功耗JDY-08BLE 4.0960096003.3V~5V无iBeacon、低功耗选型上有几个判断点值得说清楚。第一需不需要苹果手机接入。经典蓝牙 SPP 模块HC-05/06在 iOS 上基本没法直接用因为苹果对非 MFi 认证的 SPP 设备限制严格官方 API 根本不开放 SPP 通道。如果你的产品要接 iPhone只能走 BLE也就是 HM-10 这类。反过来如果你的应用只需要和安卓手机或 PC 通信经典蓝牙的配对流程更省事安卓端可以直接用系统蓝牙设置里配对然后开个串口 APP。第二数据量和实时性。经典蓝牙 SPP 在 115200 波特率下的理论极限大概是 11.25 KB/s115200 / 10 位每字节实测透传去掉协议开销在 8~10 KB/s 之间。BLE 默认 MTU 只有 23 字节有效载荷 20 字节即使连接间隔调到 20ms、每个连接事件发 4 个包也只能做到 4 KB/s 左右实测通常在 1~2 KB/s。如果协商了更大的 MTUBLE 4.2 以上支持 247 字节吞吐可以拉到 10 KB/s 以上但手机端的支持情况参差不齐。要传图片、传音频别指望蓝牙老老实实上 WiFi。第三成本敏感度。HC-06 和非品牌的 JDY-31 差价能到一半如果只是做简单的指令透传JDY-31 兼容 HC-06 的 AT 指令集替换成本几乎为零。但要注意有些便宜批次的射频指标很差隔一堵墙就掉线。我的建议是第一批样品一定买两到三个不同来源的横向跑一遍再定。2.2 硬件连线与供电90% 的诡异问题出在这里连线这块交叉接法模块 TX 接 MCU RX模块 RX 接 MCU TX是常识但有几个细节经常被忽略。电平匹配。HC-05/HC-06 模块板上通常带有 3.3V LDOVCC 可以吃 3.6~6V但它的 TX/RX 引脚电平是 3.3V 的RX 引脚一般不耐 5V。如果你用 5V 的 MCU比如经典 51 单片机直接怼短时间可能没事长时间有风险。稳妥做法是在 MCU TX 到模块 RX 之间串一个 1kΩ 电阻再在模块 RX 侧对地接一个 2kΩ 电阻做分压把 5V 拉到 3.3V。也可以用现成的双向电平转换模块。供电能力。这一条是重灾区。蓝牙模块在配对和发射瞬间的电流会有明显尖峰HC-05 峰值能到 40mA 以上HM-10 广播和连接瞬间也有十几毫安。如果你从 MCU 的 3.3V LDO 上取电而那个 LDO 只给了 100mA 余量还要供其他外设就会出现平时好好的、一配对就重启的现象。判断方法很简单示波器挂在模块 VCC 上抓配对瞬间的波形看有没有跌落到 3.0V 以下。没有示波器的话用万用表的交流档也能看出个大概的抖动。去耦电容。在模块 VCC 和 GND 之间就近放一个 10μF 的钽电容或者 22μF 的陶瓷电容再并一个 0.1μF 的高频电容这是我每次画板子都不会省的两个电容。成本不到两毛钱能省掉大量偶发断连的排查时间。EN/KEY 引脚的处理。HC-05 上电时如果 KEY有些板子标 EN引脚是高电平会进入 AT 模式波特率 38400低电平则进入正常通信模式。所以如果你不希望模块上电就进 AT 模式KEY 引脚要么悬空要么下拉。我见过有人把 KEY 直接接到 MCU 的某个 IO 上上电默认拉高结果模块一直在 AT 模式用户怎么都连不上查了两天。2.3 测试工具链从串口助手到自动化脚本基础工具三件套USB-TTL 转串口小板CH340 或 CP2102 都可以别买太便宜的有些驱动会掉线、串口调试助手、手机端蓝牙调试 APP。安卓上用蓝牙串口助手类的应用iOS 上测 BLE 用 nRF Connect 或者 LightBlue这两个能看到服务、特征、UUID、信号强度做 BLE 从机测试基本离不开。再往上一层就是自动化。手工点几百次 AT 指令肯定会疯用 Python 的 pyserial 库写个脚本把测试用例固化成函数这是效率提升最大的一步。如果你还想做手机侧的自动化用 Appium 写脚本去控制手机完成扫描、配对、收发数据的循环配合 AI 代码助手把框架搭出来一两个小时能省下后面几天的重复劳动。下面这段是我常用的串口测试骨架改改就能跑import serial import time def open_port(port, baudrate, timeout1): ser serial.Serial(port, baudrate, timeouttimeout) time.sleep(0.5) ser.reset_input_buffer() return ser def send_at(ser, cmd, wait0.6): ser.reset_input_buffer() ser.write((cmd \r\n).encode()) time.sleep(wait) resp ser.read(ser.in_waiting or 1) return resp.decode(errorsignore).strip() if __name__ __main__: ser open_port(COM5, 9600) for cmd in [AT, ATNAME?, ATUART?, ATVERSION?]: print(cmd, -, send_at(ser, cmd)) ser.close()这里有个小坑要提前说不同模块对行尾的要求不一样。HC 系列接受\r\nHM-10 建议只发\r\n或干脆不发换行部分 BLE 模块对多余字符很敏感。脚本里最好把行尾做成参数别写死。3. AT 指令测试从机测试的第一道关3.1 进入 AT 模式的正确姿势AT 模式进不去是新手最常卡住的地方。先把常见的几种进入方式列清楚。HC-05模块断电状态下按住板上小按键或把 KEY 拉高再上电板载 LED 变成慢闪约 2 秒一次此时进入 AT 模式串口波特率通常是 38400。有些批次的模块上电前 KEY 拉高即可不需要按键。HC-06没有按键上电即在 AT 模式串口波特率 9600。注意 HC-06 一旦和其它设备配对成功就不再响应 AT 指令有些固件版本需要先断开配对再上电。这是HCO6 AT 无响应最常见的原因之一。JDY-31上电即 AT 模式波特率 9600。HM-10上电后直接发 AT 就能回 OK不需要特殊引脚。但如果你之前发过ATIMME1把它设成手动唤醒模式它上电就不广播了得发ATSTART才开工。判断有没有进 AT 模式最直观的是看 LED 闪烁频率慢闪通常意味着未连接且在广播或待配快闪意味着已连接常亮或规律双闪各厂家定义不同翻手册最准。另一个判断方法是发一条AT能回OK就说明进去了。实测经验HC-05 如果上电时 KEY 是高电平但串口那边波特率还是 9600发 AT 一律无响应。别急着怀疑模块坏了先把波特率切到 38400 再试。这个错误我至少见过十几个人犯。3.2 常用 AT 指令速查与实测记录下面这张表是我实测整理的高频指令返回值为常见固件版本的表现仅供参考以你手上的模块实际返回为准。功能HC-05HC-06HM-10测试连通AT→OKAT→OKAT→OK查询名称ATNAME?→NAME:HC-05不支持查询ATNAME?→OKNAME:HMSoft修改名称ATNAMEMyDev→OKATNAMEMyDev→OKsetnameATNAMEMyDev→OKset:MyDev查询波特率ATUART?→UART:9600,0,0不支持查询ATBAUD?→OKBAUD:0修改波特率ATUART115200,0,0ATBAUD8ATBAUD8查询配对码ATPSWD?→PSWD:1234不支持无此概念修改配对码ATPSWD8888ATPIN8888无主从角色ATROLE00 从机 1 主机固定从机ATROLE0查询地址ATADDR?ATADDR?ATADDR?恢复默认ATORGL无ATRENEW重启ATRESET无ATRESET有两个格式上的坑必须强调。第一HC-05 改名用等号ATNAMExxxHC-06 用直连ATNAMExxx没有等号。很多人从 HC-05 换到 HC-06习惯性打等号结果返回 ERROR 或者干脆不回。第二HM-10 的返回都带OK前缀判断成功失败不能只看有没有OK要匹配OKset或OKNAME。实测下来HC-05 修改波特率的命令ATUART115200,0,0里后两个参数是停止位和校验位0 表示 1 位停止位、无校验。如果写成ATUART115200也能生效但有些固件会返回 ERROR建议按完整格式写。改完波特率立刻用新波特率发一条 AT 验证别忘了模块改完不会自动重启要发ATRESET或断电重上。3.3 AT 无响应的排查路径HC-06 AT 无响应这个搜索词我猜很多人搜过我自己也踩过。按下面这个顺序排查基本能覆盖九成情况。第一步确认波特率。HC-06 的 AT 波特率是 9600但它同时是通信波特率如果你之前把通信波特率改成过 115200那 AT 模式也跟着变了。所以别只试 9600把 38400、115200 都试一遍。第二步确认行尾。有些串口助手默认发的是\n或者干脆不带换行。HC 系列需要\r\n在串口助手里勾选发送新行或者在发送内容框里手动加回车换行。第三步确认配对状态。HC-06 与手机配对成功之后有些固件会拒绝 AT 指令。先把手机上的配对记录删掉模块断电重启再试。第四步确认供电和接线。把模块的 TX 接到 USB-TTL 的 RX模块 RX 接 TTL 的 TXGND 共地。这个交叉关系画反了是最常见的低级错误而且因为某些模块 TX 有上拉反接时还能读到一部分乱码让人误以为接对了。第五步确认模块本身。拿一个已知能用的模块对比测试或者把可疑模块放到另一台电脑上试。如果两台电脑、两个串口助手都不回大概率是模块固件或硬件问题。第六步看电流。用可调电源给模块单独供电观察待机电流。正常 HC-06 待机在 20~30mA 左右如果只有几毫安或者跳动剧烈模块可能已经损坏或者进入了异常状态。提醒一句排查顺序要从简单到复杂先试波特率、行尾、接线这三项花不到五分钟别一上来就拆模块换固件。4. 通信链路测试连得上、传得对、断得干净4.1 手机端连接测试从扫描到数据通路AT 配置过了只是能开机真正的从机测试从这里开始。对经典蓝牙 SPP 模块安卓端的流程是打开系统蓝牙 → 扫描 → 找到模块名称默认一般是 HC-05 或 HC-06→ 点击配对 → 输入配对码 1234 → 配对成功后打开串口 APP → 连接该设备 → 发送数据。iOS 端因为不开放 SPP这条路走不通所以如果你的产品要兼顾两端选型阶段就得定 BLE。对 BLE 模块流程完全不同。以 HM-10 为例用 nRF Connect 扫描你会看到一串设备列表找到名字叫 HMSoft 的那个点连接。连接后展开服务列表通常能看到FFE0这个服务里面有个FFE1特征这个特征同时支持 Notify模块发给你和 Write你发给模块。点开 Notify 的开关然后在 Write 里输入内容发送就能看到模块回显。这里有两个必测项很多人不做后面就会吃亏。服务与 UUID 校验。如果你的产品要求自定义 UUID避免和别的 BLE 设备混淆必须在出厂前确认模块里烧的 UUID 跟 APP 端约定的一致。HM-10 用ATUUID设置服务 UUIDATCHAR设置特征 UUID改完发ATRESET重启然后用 nRF Connect 重新扫描确认。这一步一旦漏了APP 端永远发现不了服务报错还特别含糊通常就是连接失败或者服务不存在。MTU 协商测试。BLE 默认 MTU 23意味着单次写入最多 20 字节有效数据。如果你的应用要传超过 20 字节的数据包必须测试 MTU 协商。手机端请求 247 字节 MTU看模块是否回应同意HM-10 部分固件支持部分只支持到 23。如果模块不支持而 APP 又按大包发数据会被截断而且不会有任何错误提示这种静默丢数据是最难查的。测试方法是发一个 100 字节的可识别字符串比如从 A 到 Z 循环在接收端的 Notify 回调里把数据拼起来看长度对不对。4.2 数据透传测试正确性、吞吐、误码透传测试我一般分三层做。第一层功能正确性。从主机发固定字符串从机收到后原样回传如果模块接了 MCU就是 MCU 处理后再回传校验发送和接收是否一致。测试集至少包含纯 ASCII 短包、纯 ASCII 长包200 字节以上、含中文的 UTF-8 字符串、纯二进制字节0x00 到 0xFF 全遍历。二进制全遍历这一步特别重要因为有些 MCU 端的处理代码会把 0x00 当成字符串结束符或者把 0x0A、0x0D 当成分隔符一旦你的数据里有这些字节就会出问题。第二层吞吐量实测。我习惯用固定长度的数据包循环发送持续 30 秒统计实际收到的字节数反推有效吞吐。以 HC-05 在 115200 波特率下为例串口理论极限115200 bit/s ÷ 10 bit/Byte 11520 Byte/s ≈ 11.25 KB/s蓝牙 SPP 协议开销L2CAP、RFCOMM 头部大约占 5%~10%实际可用约 9~10 KB/s这个数值可以用来判断丢数据是不是因为发得太快。如果你从 PC 端不停地灌数据而模块串口只有 9600那缓冲区一定会溢出丢包是必然的不是模块有问题。解决办法是在应用层加流控或者把发送速率降到从机处理能力之下。第三层误码与延迟。做长包连续传输用 CRC 校验每个包统计误码率。BLE 的误码率在正常环境下极低但如果旁边有 WiFi 路由器、微波炉2.4G 频段会明显受干扰。延迟测试的做法是记录发送时间戳和接收时间戳算往返时间RTTHC 系列在 9600 波特率、小包情况下的 RTT 通常在 20~50ms 量级BLE 从机则和连接间隔强相关连接间隔 100ms 的话 RTT 就不可能低于 100ms。4.3 断连重连与长时间运行测试这是最容易被跳过、也最容易在客户现场暴雷的一组测试。主动断开测试。手机端或者主机端主动断开连接观察从机模块的行为LED 是否恢复慢闪、多久恢复广播、能不能立即被重新发现。HC-05 断开后通常会在几秒内恢复广播HM-10 则要看ATIMME的设置如果设成了 IMME1手动模式断连后不会自动重新广播必须有外部触发。这个行为在真正做产品时会直接影响用户体验如果手机 APP 掉线后模块再也不出现用户会认为设备坏了。异常断开测试。正常断开和异常断开的处理路径不一样。测试方法是连接状态下直接把主机端的蓝牙关闭、或者让手机走远到信号丢失、或者给从机瞬间断电再上电。观察模块是否卡死、是否进入无法再被连接的状态。我遇到过一次HC-05 在被强制断连后偶尔会卡在一种假连接状态LED 常亮但实际已经不通了必须断电重启才能恢复。后来在固件里加了一条定时心跳检测才解决。长时间运行测试。至少跑 24 小时理想是 72 小时。测试内容是按固定间隔收发数据同时记录断连次数、重连成功率、模块温度、电流变化。判断标准是零断连或者断连后能在规定时间内自动恢复。这项测试最好在多台设备同时在场的环境下做模拟真实部署时的射频拥挤情况。单台设备跑得好不代表十台一起跑得好 —— 这一点在 2.4G 频段上尤其明显。5. 进阶场景从机控制继电器与低功耗测试5.1 从机 继电器最常见也最容易出问题的组合通过蓝牙模块控制继电器是搜索量很高的玩法从机模块加上一个 MCUMCU 解析串口指令去驱动继电器。这个场景看着简单实际测试点不少。电路上从机模块的 TX/RX 接 MCU 的串口继电器控制引脚接 MCU 的另一个 IO。如果你用的是市面上常见的 5V 继电器模块要注意触发方式和电平匹配。这类模块通常有光耦隔离输入端有高电平触发和低电平触发两种板上一般有个跳线可以切。MCU 是 3.3V 的话选低电平触发更省事因为 3.3V 输出拉低时能灌进去的电流足够让光耦导通而要高电平触发可能就推不动。还有一个高频坑继电器吸合瞬间的电流冲击会导致电源跌落进而让蓝牙模块复位掉线。我遇到过一次现象是每次开灯的瞬间蓝牙连接断开灯亮着但手机连不上了。原因是继电器线圈吸合电流大共用电源被拉垮。解决办法有三个继电器用独立电源供电、在继电器线圈两端加续流二极管、在蓝牙模块 VCC 就近加大容量电容。最省事的是第一种成本也最低。软件层面的测试点指令格式要固定比如约定以#开头、以\n结尾的 ASCII 指令模块收到后先回ACK再执行执行完回DONE。这样测试的时候有明确抓手。要重点测的边界条件包括连发两条指令去抖、半条指令只发#LI就断开、非法指令、超长指令。很多 DIY 项目的固件在半条指令面前会直接卡死因为串口接收缓冲区没做超时清空。5.2 低功耗从机测试的几个关键指标如果你的产品是电池供电从机测试的重点就完全转向功耗了。BLE 从机的功耗主要取决于三个参数广播间隔、连接间隔、以及从机延迟Slave Latency。广播间隔影响的是未被连接时的平均电流。HM-10 默认广播间隔大概 100ms 左右改成 1000ms 能把平均电流降下来一大截。测试方法是用高精度电流表或者带电流测量功能的电源记录 1 分钟的平均电流。我实测 HM-10 在广播间隔 100ms 时平均电流在 1mA 上下间隔拉到 1s 能降到 0.3mA 左右具体数值因固件而异。连接间隔影响的是已连接后的功耗。连接间隔 20ms 意味着从机每 20ms 就要醒一次收发数据功耗自然高拉到 500ms 甚至 1s平均电流能降到几百微安。但这个参数不是从机单方面决定的是主机手机和从机协商的结果。有些安卓手机强制要求最小连接间隔不低于某个值所以测试的时候要拿真机试不能只看规格书。Slave Latency是个很有意思的参数允许从机跳过若干个连接事件不应答前提是没有数据要发。比如连接间隔 100ms、Slave Latency 设为 4从机可以每 5 个连接事件才醒一次等效唤醒周期变成 500ms功耗直接降下来。测试的时候用 nRF Connect 可以看到当前实际生效的连接参数比对着测最靠谱。这里给个经验值用 CR2032 纽扣电池供电、要求续航一年的 BLE 从机广播间隔一般设 1s 以上连接间隔尽量协商到 500ms 以上平均电流控制在 20μA 以下是理想目标。做不到的话就要考虑改方案了。5.3 HC-05 连不上的典型原因清单HC05 蓝牙模块连接不上是出现频率极高的问题我把遇到过的原因整理成一份清单按排查顺序排。现象可能原因验证方法处理方式手机搜不到设备模块未上电或供电不足量 VCC 电压、看 LED换供电、加去耦电容手机搜不到设备KEY 引脚被拉高处于 AT 模式测 KEY 引脚电平下拉或悬空搜到了但连不上已有设备占用连接检查是否有别的手机连着断开旧连接搜到了但连不上配对码不对试 1234、0000、8888用 ATPSWD 重置连上后立刻断开电源跌落示波器抓 VCC独立供电或加大电容连上后收发无反应通信波特率不匹配查 ATUART 设置改成与 MCU 一致连上后数据乱码电平不匹配、地线未共量信号电平和 GND加分压电阻、共地隔一段时间就断射频干扰、天线布局差换环境对比测试远离干扰源、调整天线偶发连接失败模块固件版本问题对比不同批次换批次或联系供应商最后一条要单独说。不同批次的 HC-05 固件差异很大有的版本在 AT 指令回显上都不一样甚至有的模块出厂波特率就不是标准值。所以我的习惯是每批新到的模块先抽 3 到 5 个做一次全量 AT 指令扫描把实际返回记录存档。这份档案在后续排查问题的时候能救命因为你能立刻判断是这批模块本身和上一批不一样还是我的电路出了问题。6. 问题速查与踩坑实录6.1 排查通用思路从物理层往上走蓝牙问题排查最忌讳跳步。我总结的顺序是电源 → 地线 → 电平 → 串口参数 → 模块配置 → 协议层 → 应用层。听起来像废话但真的按这个顺序走八成问题在前三步就定位了。举个我自己的教训。有一次调一块板子HM-10 死活连不上我花了大半天怀疑是固件问题最后发现是手工焊接时模块的 GND 虚焊万用表量的时候是通的因为表笔压下去了装上外壳后就断了。从那以后我改了习惯所有蓝牙相关的问题第一步先补焊一遍 GND 和 VCC 引脚五分钟的事。6.2 那些文档上不会写的心得关于模块发热。正常工作的蓝牙模块基本不发热摸上去应该是室温。如果烫手立即断电。常见原因是 VCC 反接或者接了 5V 到 3.3V 引脚运气好只是 LDO 烧了运气不好整个模块报废。关于 AT 指令的不可逆操作。ATORGL、ATRENEW这类恢复出厂设置的指令慎用尤其是已经烧好参数准备出厂的模块。我见过有人测试时手滑发了ATORGL把改好的名字和波特率全清了一批 200 个模块要重烧。测试阶段可以把这些指令单独放一个脚本里别和日常测试混在一起。关于串口助手的选择。有些老版本的串口助手在长时间接收大量数据时会卡死导致误判为模块掉线。测吞吐的时候建议用 Python 脚本接收并落盘比图形界面可靠得多。关于多设备同测。如果同时测多个从机模块注意不要让它们互相干扰。经典蓝牙模块如果名字都一样默认都是 HC-05配对的时候很容易搞混。测试前先把每个模块改成唯一名字比如DEV-01、DEV-02这样后面查日志的时候不会抓瞎。关于日志记录。每次测试都记下日期、模块批次、固件版本用ATVERSION?查、测试项、结果、异常现象。这份记录积累三个月你会发现自己对模块的行为有了一种手感再遇到新问题能快速缩小范围。这比任何教程都管用。我个人在实际操作中的体会是从机测试真正花时间的从来不是那些能不能连上的基础验证而是边界条件下的行为确认 —— 断连之后能不能恢复、数据量大了会不会丢、多台设备在一起会不会互相干扰、电池电量低了还能不能正常工作。把这些边界场景提前测掉产品到了客户手上才不会天天给你打电话。另外如果你手头有一台逻辑分析仪能同时抓串口和 SPI/I2C 总线的话建议买一台几百块钱在排查数据到底有没有从 MCU 发出去这类问题时它能帮你省掉好几天的猜测时间。