做嵌入式开发和硬件调试的人，十有八九都经历过这种场景：功能明明做完了，测试也过了，结果到了现场或者用户手里，问题开始“随机刷新”。程序偶发卡死、串口数据偶尔丢一帧、蓝牙隔一段时间就断开一次、烧录十次有两次失败……这种偶发 bug 最磨人，因为复现不了就没法定位，定位不了就没法修复。我这两年踩过的坑基本都集中在这三类：串口通信“假故障”、蓝牙断连“取证难”、烧录失败“批次玄学”。这篇就把我实际排查过程中的思路、手段和教训一次性说清楚。

先说几个关键词：串口、蓝牙、烧录。这三个环节各自都有“偶发性”的表现，但成因和排查思路完全不一样。串口的偶发问题往往是环境和硬件在伪装，蓝牙的偶发问题多半要靠录屏和日志取证才能揪出真凶，烧录的偶发问题则经常被芯片批次和工具版本搅浑。如果你手里正好有类似的问题，照着下面的思路走一遍，至少能少走我走过的那些弯路。不管你是写单片机固件的、调 ROS2 小车的、玩 ESP32 的，还是只负责给板子烧程序的，这篇文章都适用。

1. 偶发 bug 的底层认知：先分清“三类偶发”

在动手排查之前，我建议你先想清楚一个事：这个偶发 bug 到底属于哪一类。不同类别的偶发问题，排查路径完全不同，一旦分类出错，后面所有努力都是在浪费时间。

1.1 环境偶发、设备偶发、代码偶发怎么区分

我习惯把偶发问题分成三类。第一类是环境偶发，问题只在特定环境下出现，换个环境就没了。串口在办公室好好的，一到现场就丢数据；蓝牙在家里正常，到了地铁站就疯狂断开，这些都是环境因素在作怪。第二类是设备偶发，区别只在硬件个体上，十块板子里有一块有问题，换了就好，这就是设备或者批次的问题。第三类是代码偶发，纯粹是软件逻辑里的竞态条件、溢出、时序没有处理好，和硬件环境没关系。比如串口 DMA 收发缓冲区的读写冲突、蓝牙协议栈处理超时、烧录时握手信号竞争，都属于这一类。

拿串口 DMA 来说，很多人遇到“串口偶尔丢一帧”就怀疑是硬件问题，结果换了一堆东西还是丢。这类问题十有八九是 DMA 缓冲区被覆盖了，或者半满中断和全满中断的优先级没有处理好，属于典型的代码偶发。

1.2 三类偶发对应三种排查策略

环境偶发的主攻方向是控制变量和还原现场。你要找到那个让问题出现的环境变量，可能是电磁干扰、电源纹波、温湿度，甚至是 USB 延长线的长度。设备偶发的主攻方向是对照实验和替换法，换机、换模块、换批次，找出横向差异。代码偶发的主攻方向是插桩日志和压力测试，通过高频跑测试、加打印信息，把概率性问题逼成必然性问题。

这三个策略不是互相排斥的，实际上我在实战中经常把替换法和插桩法结合起来用。先换机缩小范围，再对着日志找规律。但不管用什么策略，有一点是共通的：一定要记录现场证据。

1.3 偶发问题排查的黄金三原则

这几年我总结出三个原则，每次排查偶发 bug 都会先念叨一遍。

第一，先假故障后真故障。很多偶发问题根本不是设备坏了，而是线材老化、驱动版本错乱、供电不足、接触不良。串口通信最容易中招。第二，先取证后定位。尤其是蓝牙这种没有有线连接的场景，没有录屏、没有日志，你根本没办法跟别人描述清楚问题是什么时候发生的、发生前做了什么操作。第三，先对照后猜测。烧录失败这种问题，不要上来就说是芯片坏了、工具不行了，先拿新旧批次的料做对照实验，找到差异点再说。

2. 串口假故障：换机排除法的实操细节

串口是最容易出“假故障”的外设之一，因为它的链路太长，任何一个环节有问题都会表现为“偶发通信异常”。从上位机软件、USB 转串口芯片、驱动、线缆、电平转换电路到单片机 UART 引脚，这中间任何一环的接触不良或干扰，都能让你怀疑人生。

2.1 最常见的三类串口“伪装者”

伪装者一号是 USB 转串口模块。CH340、CP2102 这类芯片本身很成熟，但市面上兼容芯片鱼龙混杂，有些模块用的是阉割版晶振，频率漂移严重，波特率高了就丢数据。我之前调试 GD32F470 的串口，9600 波特率一切正常，调到 115200 就开始偶发乱码，换了三个 USB-TTL 模块才定位到是模块的晶振精度不够。这类假故障的典型特征是：换一个模块就好了，但原模块测起来又是好的。

伪装者二号是线材和接触。USB 线特别是 Type-C 转 USB 的线，里面四根线很容易断芯，表面看不出任何问题，传输一多就掉线。还有杜邦线，插得松一点、氧化一点点，都会造成偶发不稳定。很多人在电脑前排查半天代码问题，最后发现只是线没插紧。

伪装者三号是电平不匹配。这是最容易被忽视的。3.3V 的单片机串口接到 5V 的模块上，有些模块标称支持 3.3V，实际上逻辑高电平临界，或者需要 1.8V 电平转换的场景（比如某些 GPS 模块），用了电阻分压和三极管电路，波形边缘变差，距离一长就出错。SPI、I2C 也一样，但串口因为随便拉两根线就能连，往往最不受重视。

2.2 换机排除的具体操作步骤

我在串口假故障的排查上，已经形成了一套固定的换机流程，流程的核心思路是“逐段缩小嫌疑范围”。

第一步：替换链路的两端。先把 USB-TTL 模块换掉，如果问题消失，说明原模块有问题。如果问题还在，换一台电脑试试，排除驱动冲突和系统层面的因素。这里有一个细节，换电脑之前要先确认新电脑装的是官方驱动，Windows 自带的 CH340 驱动版本太老的话会有兼容问题。

第二步：替换中间连接件。换一根全新的 USB 线，尽量短一些，不要用延长线和 hub。实测下来，USB hub 导致串口偶发断连的概率非常高，尤其是那种不带供电的便携 hub。

第三步：板级替换。把疑似有问题的板子换到另一套已知正常的设备上，跑同样的通信压力测试（比如持续发送大块数据、循环发送随机数），如果新板子正常，那基本锁定原板子硬件异常；如果新板子也异常，那就是代码或上位的环境问题。

第四步：回原机验证。这是很多人会漏掉的一步。你把换下来的设备再插回去，如果问题又出现了，说明问题跟着这个设备走；如果插回去问题没了，说明是接触不良，不是设备坏了。

这里必须强调一下，换机排除法有个前提条件：你手头至少要有两套完整的可替换件。只有一套设备的时候，这个方法是无效的，你只能靠仪器测量来辅助判断。

2.3 串口偶发问题的几个快速验证技巧

除了换机，我还会配合几个快速验证技巧来加速判断。

用串口调试助手的循环发送功能做压力测试，9600 波特率不够，要往上调，115200、460800 都试一遍。波特率越高，对时序、晶振、线材的要求越高，假故障暴露得越快。

在单片机侧翻转空闲 GPIO，用示波器或逻辑分析仪对比看串口 TX 脚的电平波形和 GPIO 翻转波形之间有无异常间隔，可以快速判断是代码卡死还是硬件假死。没有示波器的时候，用 LED 也行，直接把 LED 接在串口 TX 脚附近，闪烁是否规律一眼就能看出来。

尽量在 PC 端和嵌入式设备端都加上带时间戳的日志输出。哪怕只是最简单的“进入发送函数”“进入接收中断”这类标记，也能在事后回看日志时掌握问题的发生规律。我见过很多只跟踪一端的日志，结果另一端早就发疯了，自己还不知道。

给一个我踩过的真实案例：STC8G1K08A 的串口偶尔收不到上位机指令，排查很久。把板子上电后不要做任何操作，等几十秒再发指令就正常，如果上电后马上发指令就大概率丢第一条。最后发现是固件启动时串口初始化和外部看门狗初始化有先后冲突，这不是硬件假故障，而是代码问题。所以串口问题到最后，还是要回看代码逻辑。

3. 蓝牙断开：录屏取证是关键环节

蓝牙问题是所有偶发 bug 里最恶心的，因为它的链路是“无线”的，你看不见摸不着，而且断开之后往往没有任何现场痕迹。我调试过 HC05 蓝牙模块、ESP32 的蓝牙通信、还有手机连接蓝牙键盘的场景，遇到最多的问题就是“用着用着自己就断了，然后一会儿又能连上”。

3.1 蓝牙偶发断连为什么这么难查

蓝牙断连难查的原因有三个。

第一，无报错。大多数蓝牙模块在断开时不会主动上报原因，如果你的代码没有做连接状态监听，那就只能看到“数据发不出去了”，根本不知道是什么时候断开的。第二，强环境依赖。2.4GHz 频段本身就拥挤，Wi-Fi、USB 3.0 接口、微波炉、其他蓝牙设备都会干扰。同一个模块在实验室没问题，到了办公室或者展会现场就频繁断开，环境变量太多了。第三，复现随机性大。有时候一天都不断一次，有时候一小时断五次，你根本没法稳定复现，也就没法在中断的时候抓现场。

尤其是杰理蓝牙、HC05 这类从模块，内部的协议栈状态你没法直接观测，只能通过 AT 指令间接查询。AT 指令本身又是串口通信，又有可能引入新的变量。

3.2 录屏取证的两个要点：录什么、怎么录

我为什么特别强调录屏取证，因为蓝牙问题光靠嘴说没用，你说“它自己断了”，别人没法验证。但如果你能拿出录屏，显示连接状态从“已连接”变成“断开连接”，这个过程就是铁证。

录屏不是什么都要录，要有选择地录。我的做法是把手机或者电脑的蓝牙设置页、你自己的 App 操作界面、以及系统日志（如果有的话）同时录进去。在开始录屏之前，先做一次时间同步。手机和电脑都对一下网络时间，确保录屏上的时间戳和系统日志的时间戳可以对应上。这个细节很重要，否则录完之后时间对不上，你依然没办法定位。

录屏的内容里必须包含以下几个关键要素：

• 连接建立成功的瞬间（看状态变化）
• 操作触发的动作（比如点了一个什么按钮、发送了什么数据）
• 断开发生的瞬间（看状态从连接到断开的变化）
• 断开前的最后几秒操作（可能是关键触发条件）

3.3 录屏之外的“证据链”建设

录屏只是第一步，光有录屏还不够，你还需要建设完整的证据链。我的做法是给蓝牙模块加一个日志输出接口，把所有关键事件通过串口打印出来。模块掉线了不要紧，串口日志还在。

在 MCU 侧添加事件日志记录，记录内容包括：

• 蓝牙初始化完成的时间点
• 连接建立的时间点（打印远端地址）
• 收到数据的每一帧字节数和校验结果
• 发送数据的时机
• 连接断开的时间点（如果 MCU 能捕获到状态回调）

在 App 侧也要加日志。我看过很多 App 的蓝牙逻辑图，连接状态机的处理一团糟，各种回调顺序没有理清。MTU 协商失败、GATT 操作超时、扫描结果过滤不合理，都会造成“假断开”或者“真断开但 App 没感知”。

这里补充一个开展方向：大量蓝牙断连问题源于未能正确处理 MTU（最大传输单元）。安卓端某些版本默认 MTU 是 23 字节，如果你硬要一次发 512 字节的数据，协议栈就会把大包分包，分包过程一旦出错，连接就挂了。用requestMtu把 MTU 协商到 185 或者 512，问题通常会缓解很多。

3.4 录屏取证如何指导换机排查

录屏取证还有一个好处，就是能给换机排查提供方向。比如我用录屏发现某个蓝牙键盘是在系统休眠唤醒之后立刻断开，这个现象在多个键盘上都出现，那就可以初步判断问题出在系统的蓝牙协议栈，而不是键盘本身。再比如录屏显示蓝牙断开之前 App 界面上出现了某个异常弹窗，那就要重点排查 App 的逻辑，而不是硬件。

另外，A2DP 切 SCO 模式这个场景也值得关注。音频设备在通话状态下会从 A2DP 切换到 SCO，如果切换逻辑没处理好，就会表现为“音乐听着听着断了”。这个场景同样可以通过录屏取证来确认，录屏上能明显看到音频输出设备的变化轨迹。我见过排查安卓蓝牙音质问题的人，最后就是用录屏确认了 SCO 切换时机异常，修改了切换策略才解决的。

4. 烧录排查：“新旧批次对照”的工程思维

烧录问题是嵌入式开发里的另一大“偶发专业户”。KEIL5 里编译成功，点烧录就是失败；Arduino IDE 编译完下载，偶尔提示板子没有响应；ESP32 的烧录方式明明设置正确，就是连不上开发板。这些问题表现各异，但有一个共同点：有时候和芯片批次、工具版本、通信时序强相关。

4.1 烧录失败的两种类型：工具性问题与器件性问题

工具性问题好排查，无非是驱动没装好、烧录器没识别、端口被占用、供电不足、BOOT 引脚没有拉低。ESP32 烧录失败最常见的原因就是 BOOT 模式没进对，需要把 GPIO0 拉低再上电。Arduino Uno 给 Uno 板烧录引导（bootloader）失败，往往是因为忘记在烧录前断开目标板的串口连接、ISP 引脚接线有误，或者目标板的时钟源设置不对。

器件性问题就比较复杂了，尤其是芯片批次造成的差异。同一个型号的芯片，不同批次可能在内部上电时序、flash 属性、模拟性能上有细微差别。我遇到过 GD32F470VET6 的芯片，A 批次烧录一切正常，B 批次烧录偶尔失败，失败后重新上电又能烧进去。一开始以为是烧录器问题，换了烧录器、换了两根杜邦线、换了电脑 USB 口，问题依旧。最后拿新旧两个批次的芯片做对照实验，发现 B 批次芯片的复位时序要求更严格，烧录器发出的复位信号宽度不够，导致握手失败。解决方案是调整烧录器的复位延时参数，或者外接一个 RC 延时电路。

4.2 “新旧批次对照”实验怎么设计

“新旧批次对照”这个方法，本质上是一种受控的变量实验。核心逻辑是：当你怀疑一个偶发问题和批次相关时，不要直接去查芯片手册，先做一个横向对比实验。

第一步：准备样品组。从新批次里取三到五颗芯片，从旧批次里也取三到五颗，保证样本量足够，避免单颗芯片的个体差异干扰判断。第二步：固定变量。烧录器、烧录软件版本、电脑、USB 口、线材、烧录参数全部一致，只改变芯片批次。第三步：记录烧录成功率。每个批次重复烧录十次以上，记录失败次数和失败时的具体表现（失败在擦除阶段、写入阶段还是校验阶段）。第四步：交叉验证。如果新旧批次存在明显差异，再拿新批次的芯片放到旧批次的整套设备里烧录一次，确认不是设备问题；反过来也一样。

我特别推荐做一张这样的对照记录表，方便直观对比：

表格的好处在于，它能帮你快速看出差异集中在哪一列。如果失败只和新批次、KEIL5.38 这个组合相关，那么嫌疑就在“新批次芯片和当前工具链的兼容性”上，方向也就明确了。

4.3 烧录对照排查中的常见坑

批号对照实验有几个常见的坑，我都踩过。

第一个坑是“伪对照”。你把烧录器换了一个型号，把电脑也换了，把线也换了，然后说这是对照实验，其实变量太多了，结果根本没有参考价值。真正的对照实验一次只能变一个变量。

第二个坑是“寄存器级差异”。不同批次的芯片可能在出厂时固化了不同的 flash 等待周期或者选项字节（Option Bytes），这些寄存器配置的差异会影响烧录的稳定性。建议先读一下新旧批次芯片内部的基础配置，对比一下有没有预置差异。

第三个坑是烧录工具本身版本的差异。乐鑫烧录工具 v3.6.5 和旧版的默认参数可能不一样，sdkmanager烧录 super 模式又和普通分区烧录的模式不一样。KEIL5 的烧录算法文件（FLM）如果是从旧版本工程里拷贝出来的，可能跟不上新芯片的 flash 规格。这些都是偶发“玄学”失败的真实来源——不是芯片玄学，而是工具链太旧认不出新料。

举个例子，之前用pwllink2烧录 STM32 芯片，老是提示“RDDI-DAP Error”，后来发现是烧录器固件版本太老，升级之后彻底解决。所以烧录偶发失败的时候，先别急着怀疑芯片，先把烧录器固件、烧录软件版本、算法文件全部更新到官方最新版，再跑批次对照实验。

4.4 AT89S52、eeprom 这些特殊场景的烧录细节

除了主控芯片，还有一些特殊烧录场景也值得讲一下，遇上了记得避开坑。

AT89S52 这种老古董单片机，用的是 ISP 下载方式，但它和常见的串口 ISP 不太一样，需要专用的下载线（通常并口或 USBASP）。有些人电脑上没有并口，只能找 USBASP，而 USBASP 的驱动在 Win10/Win11 上非常容易出兼容问题，表现为“连接成功但烧录时校验不通过”。这个和串口假故障是同一类问题，换一条下载线、换一个 USB 口、换台电脑，通常会解决。

eeprom 烧录（比如 24C02、24C256）容易出问题的点是总线时序。有些编程器只支持标准模式（100kHz），不支持快速模式（400kHz），如果你的软件设成了快速模式，就会偶发写不进去。这种问题的排查方法也很简单：降低写入速度，看是否稳定复现。

STC8G1K08A 的烧录接线也有讲究，它的下载引脚要接对，而且 STC 的 ISP 下载有个特点：冷启动下载。也就是说，必须先让软件进入“等待下载”状态，再给目标板上电，顺序反了就会一直提示“正在检测单片机”。很多人第一次用 STC 的时候都栽在这个流程顺序上。

5. 偶发 bug 排查的工具箱与经验清单

讲完串口、蓝牙、烧录三类具体问题，我还想总结一下通用的排查工具箱和经验清单。这些工具不贵，大部分免费，但能极大提升排查效率。

5.1 日常排查的软硬件工具箱

硬件方面，我建议至少常备以下装备：一个好的 USB-TTL 模块（推荐原装 CH340G 或者 CP2102，避开那些几块钱的山寨版）；一套质量好的杜邦线和一根短的 USB 线；一个逻辑分析仪（二十几块钱的 8 通道逻辑分析仪就够用，采样率 24MHz 足以分析 115200 波特率的串口）；有条件的再搞一个示波器，不用太好，100MHz 带宽的双通道就行。

软件方面，串口调试助手是标配，但要选支持时间戳的。虚拟串口软件（比如 VSPD）在调试上位机和下位机通信的时候很好用，可以在没有实际硬件的情况下模拟串口收发。蓝牙调试方面，谷雨蓝牙调试工具之类的小工具可以用来查看 MTU、服务列表和特征值，排查连接问题很有帮助。

5.2 排查前的“五分钟检查清单”

每次遇到偶发 bug，我都会先走一遍五分钟检查清单，不要一上来就深挖代码。

检查供电是否稳定——很多偶发问题都是从电源纹波开始的，尤其是驱动舵机、电机、Wi-Fi 模块的时候，瞬时电流波动会让 MCU 掉电重启，表现就是“用着用着串口断了”“蓝牙断开了”。检查所有物理连接——线头有没有松、插头有没有氧化、排针有没有虚焊。这个问题被忽略的概率超过了你的想象。检查工具链版本——驱动是不是最新版、烧录算法库是不是和芯片匹配、IDE 版本有没有已知的兼容问题。检查环境干扰源——附近有没有大功率电机、无线充电器、微波炉等设备。

5.3 排查记录的规范化

这个习惯我强烈建议你们养成：每次排查偶发 bug 都写排查记录。不用写得很复杂，把时间、现象、环境、做过哪些操作、结果如何记清楚就行。

我个人的习惯是：每排除一个变量，就用红笔在记录本上划掉一个假设。这个动作看起来简单，但能防止你陷入“来回查了一圈又回到原点”的困境。排查记录还有一个作用——当你需要求助别人的时候，一份完整的排查记录比一句“我的板子有 bug”有效一百倍。

5.4 心态管理：偶发 bug 排查是一场持久战

最后聊一点心态问题。偶发 bug 之所以难搞，是因为它的复现概率低、证据链不容易构建、变量太多。很多工程师在被偶发 bug 折磨几天之后，就开始怀疑自己的代码，甚至怀疑人生。根据我的经验，绝大部分偶发 bug 最终都能定位到一个非常具体的原因，只是排查的时间长短问题。

所以我的建议是：接受“偶发 bug 可能要花几天时间”这个事实，不要焦躁。按照替换法和对照法的思路一步步走，把每一次复现都当作一次采集证据的机会，把每一个失败都当作排除一个变量的过程。只要证据链完整、变量控制得当，那个隐藏的 bug 一定会现出原形。

我自己最难的一次偶发 bug 排查花了整整四天，最后定位到一个 STM32 HAL 库的串口 DMA 半满中断处理中，一个__HAL_DMA_GET_COUNTER的返回值在特定时序下读到了旧值，导致缓冲区尾部几个字节被覆盖。找到原因之后，修复只花了一行代码。但那四天的排查过程，让我对串口时序、DMA 行为、芯片 errata 的理解都深了一层。后来再遇到类似问题，我的直觉判断就准了很多。排查偶发 bug 最大的收获，不是你解决了一个问题，而是你锻炼了一套方法论。这套方法论的落脚点，就是标题里那句话：换机排除、录屏取证、新旧批次对照。