串口假故障、蓝牙偶发断开、烧录偶尔失败，这三类问题的共性都是“偶发”。只要带上“偶发”两个字，排查难度立刻翻倍，因为很多工程师习惯性地先怀疑软件逻辑，又把精力浪费在不稳定的复现上。我做了多年嵌入式开发和硬件联调，对这类型问题最大的感受是：偶发 bug 不是技术难题，而是证据问题。手里没有可靠证据，再高明的猜测也只是碰运气；证据链完整了，排查方向自然就出来了。下面我把串口换机排查、蓝牙断开的录屏取证、新旧批次对照烧录排查这三个场景完整拆开讲，基本就是我实际工作中的排查套路，你可以直接抄作业。

1. 偶发 bug 的排查思路：先判真假，再定工具

偶发 bug 之所以让人头疼，核心原因是它不遵循“稳定复现”的排查前提。按我自己的经验，接到这类问题后，第一步不是打开代码找逻辑，而是先把问题定性，确定它到底是个真 bug，还是由外部因素造成的“假故障”。

1.1 真假故障的判断逻辑

在嵌入式开发和设备联调中，故障通常来自三个层面：硬件电路、底层驱动、应用逻辑。偶发问题的复杂性在于，这三个层面都可能表现为同样的现象。比如一个串口偶尔收不到数据，可能是 MCU 的 UART 配置有问题，也可能是 USB 转串口芯片驱动被系统更新搞坏了，还可能是线缆接触不良。

判断时，我会先问三个问题：

• 问题是否和特定设备强绑定？换一台设备后是否立刻消失？
• 问题是否和特定环境强绑定？换一根线、换一个 USB 口、换一台电脑后表现是否一致？
• 问题是否和操作时序强绑定？每次操作方式相同，是否能稳定触发？

如果一个偶发问题换设备后彻底消失，那大概率是设备侧的问题；如果换环境后消失，大概率是环境侧的问题；只有两条都不成立，才应该回到代码和电路层面去深挖。这个顺序反过来的话，很容易出现“调试了三天最后发现是 USB 线老化”的尴尬局面。

1.2 偶发问题最常见的两个坑

我做过的项目里，偶发 bug 排查失败的原因，大部分不是技术不够，而是踩了下面这两个坑。

第一个坑是“只记录结果，不记录现场”。很多工程师遇到偶发问题，习惯在代码里加打印，然后等它出错再回头分析。但偶发问题发生时的环境状态、操作过程、外部设备连接情况这些信息特别关键，单单靠串口打印往往只能看到现象，看不到触发条件。比如串口偶发断连，如果当时没有记录系统事件和外部设备信息，后面想去复盘根本无从下手。

第二个坑是“用修代替查”。一旦问题不定了，就直接怀疑是某个元件坏了、某个芯片有问题，先换再说。换了之后问题暂时没出现，就默认解决。实际这种做法对偶发问题来说特别危险，因为偶发本身就有概率性，你今天换了可能明天又出来，连原始现场都丢了。

1.3 先建立“证据优先”的排查原则

现在我做偶发 bug 排查，第一准则就是：任何结论都要建立在可回放的证据上。这里的证据不只是日志，还包括操作录屏、硬件连接照片、设备批次信息、软件版本号，甚至风扇转速、环境温度这类物理参数。

有了证据再来定方向，就不会出现“公说公有理，婆说婆有理”的情况。我经历过一次串口乱码问题，硬件工程师说是软件时序问题，软件工程师说是硬件电平问题，最后一起看录屏才发现问题只出现在某个特定手速很快的操作步骤之后，和电平时序关系不大，纯粹是软件初始化没做完就去发数据了。

提示：偶发 bug 排查，先做故障定性，再选排查工具。哪怕一开始定性判断是错的，也比没有定性就到处乱试要强得多。

2. 串口假故障：换机排查如何做交叉验证

串口是嵌入式开发里最常用也最容易出现“假故障”的外设接口。这里我说的“假故障”，不是指电路或软件真的坏了，而是设备本身没问题，但用户操作层面、驱动层面、线缆层面的因素让它表现出“坏了”的现象。一旦被假故障带偏，最常见的做法就是反复检查代码，结果越查越糊涂。

2.1 串口假故障的典型特征

我总结下来，串口假故障一般具有这几个特征：

• 现象偶发或轻微，比如偶尔丢字节、偶尔打开失败、偶尔乱码。
• 重启设备或重启电脑之后，故障可能自动消失。
• 故障发生时，用示波器看波形往往又是正常的。
• 换一个串口工具软件测试，故障表现不一致。

这几个特征都指向一个结论：这不是 MCU 或外设电路的稳定逻辑问题，而是链路中某个薄弱环节偶尔出现问题。薄弱环节可能在线缆，可能在 USB 转串口芯片的驱动，可能在电平转换电路，也可能在串口工具的配置上。

2.2 换机排查的标准步骤

换机排查的关键在于“交叉验证”。实际操作时我一般按这个顺序来：

第一步：固定软件环境。先保持上位机软件版本、串口参数、操作系统环境完全一致，排除软件变量。

第二步：更换 USB 线。串口假故障里，线缆是最大嫌疑对象。很多 USB 转串口线表面看着没问题，实际上内部铜芯很细，或者屏蔽层已经断裂。换一根短而粗的线，故障如果消失，问题基本就锁定在线上。

第三步：更换 USB 口。有些 USB 口供电能力不足，插上串口模块后电压跌落，导致通信不稳定。特别是笔记本的某些 USB 口，或者通过集线器扩展的口，很容易出这个问题。直接换到主板自带的 USB 口再试。

第四步：更换电脑。这一步是整个流程的分水岭。同一串口模块、同一根线，换到另一台电脑上测试。如果换机后故障消失，说明原电脑的环境有问题，可能是驱动冲突，也可能是系统 USB 栈被某些软件干扰；如果换机后故障依旧，那大概率是串口模块本身或目标设备的问题。

第五步：更换串口模块。用一块全新的、已知没有问题的 USB 转串口模块替换原来的模块。换完问题消失，原模块有问题；换完问题还在，那就是目标设备侧的问题，重点回到目标设备的电路和固件。

用表格来总结的话，一个完整的换机排查矩阵长这样：

2.3 CH340、FTDI 等驱动的混用坑

换机排查时，有一步很多人会忽略：驱动版本。国内常用 CH340，海外开发板常用 FTDI，两者装上驱动之后，在设备管理器里都显示为“USB Serial Port”。如果你同时在多台电脑上插过不同的 USB 转串口模块，Windows 可能会给同一个 COM 端口号绑定不同的驱动实例，造成端口号错乱。

我的亲身经历是：一块 ESP32 开发板偶尔上传失败，编译每次都成功，就是烧录时找不到串口。打开设备管理器，看到 COM3 正常识别，但重新插拔后 COM 号变成了 COM5，而某个老的 FTDI 驱动还占着 COM3。这种问题你如果只靠换机排查，往往很难发现，因为每台电脑的情况都不一样。建议换机测试时顺手做一个动作：在设备管理器里把“USB Serial Port”卸载，再重新扫描硬件改动，让系统重新分配驱动，然后再测试。

2.4 串口假故障排查中的留证技巧

换机排查过程中，一定要做好记录。不要觉得这一步没用，实际排查到后面，你很容易忘记哪根线已经试过、哪个口有问题。我现在习惯用一个最简单的办法：每次换一个变量，就在笔记本上写一行字，条件写清楚，结果写清楚。

有些更隐蔽的假故障，还需要借助虚拟串口工具来留证。比如你怀疑是某个串口调试助手软件抢占端口，可以先用虚拟串口软件创建一对虚拟串口，再让两个串口工具分别打开两端，测试数据收发。如果虚拟串口工作正常，说明系统串口栈没问题，问题就在真实硬件链路。

3. 蓝牙断开问题：录屏取证与日志时间线对照

蓝牙设备的偶发断开，我做过不少项目，包括 HC05 蓝牙串口模块、ESP32 的 BLE 连接、手机与蓝牙仪表的通信等等。蓝牙断开的难处在于，它很多时候是“现场无法复现，回头出问题你根本看不到过程”，尤其在测试人员和开发人员不是同一个人的情况下，口头描述会失真。这时候，录屏取证就是最有效的武器。

3.1 蓝牙偶发断开的难点在哪里

蓝牙本身是无线通信，链路质量受环境影响很大：2.4G 频段的 WiFi 干扰、微波炉辐射、人体遮挡、距离变化，都会导致瞬时数据丢失，甚至触发底层重连机制。再加上很多 MCU 上的蓝牙方案，底层协议栈跑在单独的核心里，应用层拿到的事件往往已经被“修饰”过，你看到的“断开”可能是好几个层叠原因的结果。

这就导致一个局面：你让测试人员去复现断开问题，他操作半天没反应，你一转身，他就说“刚刚又断了”。这种情况下，没有录屏、没有日志，后面所有分析都是无根之木。

3.2 录屏取证的具体做法

针对蓝牙断开的录屏取证，我推荐做“双通道记录”：一边录屏幕上的测试界面，一边录蓝牙模块侧的运行状态。屏幕录制的重点不是看画面，而是看时间点。当界面显示“断开”事件的那一帧，往回倒看是什么操作触发的、当时信号强度图标是什么状态、有没有在这之前出现过卡顿。

具体工具上没有特殊要求，Windows 上用 Xbox Game Bar 或者 OBS，手机端可以用系统自带的录屏功能。这里有个关键技巧：录制时把系统时间打开显示，或者让一个计时器程序挂在屏幕角落。方便后续和蓝牙日志做时间对齐。

如果是调试 HC05 这类蓝牙串口模块，录屏的同时要开一个串口调试助手，把模块发出的 AT 返回和透传数据都记录下来。断开那一刻，串口端有没有收到乱七八糟的数据，是非常关键的判断依据。我之前遇到过一次 HC05“连接后经常掉线”的问题，后来看录屏发现，每次界面出现“断开”之前，串口助手都会先收到一大段乱码。顺着这个线索排查，最后定位到模块供电电压在蓝牙射频发射瞬间跌落，导致模块复位重连。

3.3 抓取蓝牙协议日志：不要只盯应用层

录屏只能证明“什么时候断了”，但断的根因，需要蓝牙协议日志来补充。在安卓开发中，最方便的是开启开发者选项里的“蓝牙 HCI 抓包”，系统会把蓝牙协议栈内部的事件保存成 BTSNOOP 文件，用 Wireshark 打开就可以看到连接参数更新、断连原因、RSSI 变化等底层信息。

在 Windows 上可以开启蓝牙事件跟踪日志，或者用 Wireshark 配合 USBPcap 抓取蓝牙适配器发出的 USB 总线数据，也能分析出协议层的行为。这个操作看起来麻烦，但做一次就值了，因为蓝牙断连的原因里，最常见的几个都能在协议日志里找到影子：

• 连接参数更新失败或超时，导致链路监督超时。
• 从设备没有及时回复连接事件，主设备主动断开。
• 切换蓝牙模式时协议栈状态异常，比如 A2DP 切到 SCO 时偶发失败。

3.4 HC05 与 ESP32 蓝牙场景的专项检查点

如果是 HC05 这类经典蓝牙模块，偶发断开排查时除了看协议日志，还要重点检查几个点：模块的波特率设置是否和 AT 指令输入一致，模块是否工作在从机模式但被多个设备反复连接过，以及模块的 PIO 状态引脚有没有正确接到 MCU。我还遇到过一种情况是 HC05 模块进入 AT 模式后，数据模式被意外改写，导致连上后又立刻断开。

如果是 ESP32 做 BLE 外设，排查时要额外留意广播参数和连接参数设置。ESP32 的 BLE 默认连接间隔、从机延迟和超时时间，如果和主设备的要求不匹配，就会出现连接后很快断开、但是偶尔又能持续很久的现象。这时候不要盲目改代码，先把主设备侧的连接参数日志拉出来对照一下。

注意：录屏取证不是为了“甩锅”，而是为了建立统一的时间线。拿到录屏后第一件事，是标记出故障发生时刻前后 10 秒内的所有操作和现象，之后再结合协议日志逐帧分析。

4. 新旧批次对照的烧录排查

烧录问题属于那种“看起来很简单、实际上很玄学”的类别。Keil 编译成功但烧录失败、ESP32 下载程序时偶发连接失败、新到的板子用旧固件烧录就是不行……这些现象如果稳定复现还好，最怕的是同一套工具链，昨天行、今天不行，或者旧板子行、新板子不行。这种时候我建议直接做“新旧批次对照”。

4.1 为什么烧录问题和硬件批次有关

很多人写代码写得久了，容易忽略一个事实：烧录过程不只是“软件把 hex 文件写进芯片”，而是一个严格的时序握手过程。以 STM32 的串口 ISP 烧录为例，芯片上电后需要检测 BOOT0 引脚的电平状态，然后内部固化的 Bootloader 开始和上位机通信。如果新批次 PCB 上 BOOT0 引脚悬空处理方式变了，或者复位电路的电容器件参数变了，都可能导致进入 Bootloader 的时机不对，从而出现偶发的烧录失败。

ESP32 那边情况更明显。ESP32 的下载模式需要在上电时拉低 GPIO0，如果新批次板子的 GPIO0 外部上拉电阻或者连接的模块引脚有细微差异，在 USB 转串口芯片和主控上电时序稍有变化时，就可能进不了下载模式。

所以，当出现“旧板子可以，新板子不行”的现象时，我的第一反应不是去调烧录工具的参数，而是把新旧两块板子摆在一起，做硬件层面的对比。

4.2 新旧批次对照排查的标准流程

新旧批次对照的核心原则是：物理上找差异，逻辑上做二分。我每次做批量问题排查，都按下面这个流程走：

第一步：确认批次边界。先找出哪一批板子开始出问题，向生产要这一批的物料清单、工艺改动记录、生产日期和产线编号。这一步能缩小很多怀疑范围，有时候问题根本不在设计，而在于某一次贴片机换料时换了个等效但参数不同的电容。

第二步：做同条件交叉烧录。用同一台电脑、同一个烧录器、同一固件版本，分别去烧录旧板和新板。至少烧录 20 块样本，记录失败率。如果旧板 100% 成功，新板 30% 失败，就可以确定是新板批次的问题。

第三步：对比关键电路。重点看电源去耦电容、复位引脚、模式选择引脚几个位置。用万用表量静态电平，用示波器看芯片上电时的电源爬坡曲线和复位时序。很多时候，新板子某个引脚电平因为分压电阻的阻值偏差，正好卡在芯片高低电平阈值附近，导致偶发工作正常、偶尔不正常的现象。

第四步：逐板记录序列号。如果烧录失败不是全部板子，而是集中在某几个序列号区间，要去看这些板子是不是同一台贴片机、同一个操作员、同一批锡膏。这种“人和线绑定”的因素，在批量排查里不能忽略。

我用表格整理一下对比维度，你在实际项目中可以直接用：

4.3 Keil 和 ESP32 烧录踩过的具体坑

在 Keil 环境里，偶发烧录失败最常见的坑，不是硬件问题，而是 IDE 和后下载器之间的握手冲突。比如使用 ST-Link 时，如果目标板在烧录瞬间未复位，或者调试接口和某几个 GPIO 复用了，就会报 “Cannot access target”。这类问题你用换机排查很难发现，因为代码编译没问题，换下载器可能也能好，但过两天又出。

我的经验是：先把下载器和目标板之间的连线缩短并改成双绞方式，排查干扰问题；然后在 Keil 的 Flash Download 配置里，把 Reset and Run 选项勾上，并把下载速度从最高档往下调一档。很多偶发失败，就是因为下载速率太快，目标板上电瞬间还没有准备好。

ESP32 的烧录失败，我最常遇到的情况是用 esptool 下载时提示 “Magic number mismatch” 或 “A fatal error occurred: Failed to connect to Espressif device” 。这类问题十有八九是串口进入下载模式的时序不对。排查方法很简单：用串口工具手动打开对应端口，波特率设为 115200，然后按住开发板的 BOOT 键再按一下 RST 键，最后松开 BOOT，看串口工具里有没有出现 “Download started” 类的信息。如果没有，说明硬件根本没有进入下载模式，这时候再回头查 GPIO0 和 EN 引脚的批次差异。

4.4 烧录固件本身的校验辅助

除了硬件批次，烧录排查还需要检查固件文件本身是否在不知不觉中发生了变化。我习惯在对比批次时，把旧板子里正在跑的固件用烧录器读出来，和新编译的 hex 文件做一次校验。方法很简单：用 Beyond Compare 或者直接在命令行下用sha256sum对比两个文件的哈希值。

有时候编译环境会自动改变某些配置，比如编译器版本升级后，相同代码生成的机器码会有细微变化，而这些变化正好触发了一个隐藏 bug。如果旧板子跑得稳、新板子跑得炸，先做一次固件哈希对比，能快速排除“代码悄悄变了”这个可能。

注意：新旧批次对照绝对不是“拿新板子怼回去”这么简单。真正有价值的部分是“对照”本身，哪怕最后发现新板子没有问题，这个对照过程也能帮你排除一大片疑问。

5. 偶发 bug 排查的通用经验：记录、复现、复盘

说了三个具体场景，最后想聊聊偶发 bug 排查里通用的东西。这些经验不是我一天总结出来的，是踩过很多次坑之后才慢慢形成的习惯，写出来供你参考。

5.1 日志抢救的五分钟原则

偶发问题发生后，第一件事不是尝试修复，而是抢救现场。我给团队成员定的规矩是：问题发生后的五分钟内，先做这样几件事——截图、录屏、保存日志、记录当前操作步骤、标记设备序列号。这五分钟抢救出来的信息，往往比后面调试三天得到的信息更有价值。

就拿蓝牙偶发断开来说，问题刚发生时，系统日志里还保留着全套的底层连接信息，你只要多等一会儿，日志滚动过去了，底层信息就被覆盖了。这时候再去翻日志，已经找不到原始原因，只能靠猜测。

5.2 复现时的“变量控制记录表”

复现偶发问题，核心是控制变量。我平时会画一张简单的表，每次测试只改一个变量。表头包括：时间、测试人员、设备编号、软件版本、操作步骤、环境条件、结果、备注。比如测试蓝牙断开，就分别在不同距离、不同干扰源、不同设备配对下测试。这张表积累到一定量，规律自然会浮出来。

没有这张表之前，我经常会被测试人员的“我随便点了点就断了”这种描述折腾很久。有了表之后，至少可以缩小范围，知道“哪个变量变化时问题更容易出现”，也就找到了触发条件。

5.3 换机排查不等于推卸责任

最后一点，我要给团队合作场景提个醒：换机排查、录屏取证这类的操作，在跨岗位协作时容易被误解为“互相甩锅”。硬件问题说是软件的，软件问题说是硬件的，烧录问题又说是治具的。实际上，证据导向的排查方式，反而能大大减少无意义的争论。

我在推进这类排查时，会说得很清楚：“我们不是要找责任人，而是要找到变量。谁提供的证据越多，越能帮大家少走弯路。”录屏把问题时间点定下来，换机把故障边界定下来，批次对照把方向定下来，剩下真正定位到代码或者电路的哪一行，反而不难了。

5.4 排查完成的最后一步：把偶发变必然

偶发问题“解决”之后，还有一个很多人会漏掉的收尾工作——把故障触发条件固化下来，让问题从偶发变成必然。比如锁定了是某个 USB 口供电不足导致串口模块掉线，那就修好供电电路后在测试规范里加一条“所有串口测试必须使用独立 USB 口”；再比如锁定了是新批次某个电阻阻值偏离导致烧录失败，那就和产线说清楚这个物料必须换成何种精度等级。

这一步不是在小题大做。项目可能就做一次，但同样的错误，换个项目换个板子还会再犯。把偶发问题沉淀成测试用例、设计规范，才算是真正把这次排查吃透了。

我在实际项目中，最深的体会是：偶发 bug 之所以难，不在于它技术上有多深，而在于它太容易让人失去耐心，转而依赖“换一块板子试试”这种没有系统性的操作。只要你愿意在排查前先花十分钟想清楚三个问题——证据在哪、边界在哪、变量在哪——剩下的工作就是按部就班。哪怕最后没有在当天定位到根因，你积累下来的证据链，也足以让任何一次专家会诊快速指向真相。