企业官网建设流程全解析

做了几年蓝牙设备测试，我最大的体会是：很多“蓝牙连不上”的bug，其实并不是蓝牙本身出了问题，而是测试工具没选对。手机能搜到信号、模块灯在闪、PC能识别适配器，这些步骤只要有一步没验证清楚，后面就会反复在同一个坑里打转。

这篇就把我自己一直在用的蓝牙连接测试工具和排查思路整理出来。从手机上最快的调试App，到PC端的抓包分析，再到ESP32、HC-05这类嵌入式模块的实测脚本，基本上覆盖了日常开发里遇到的大部分连接场景。不管你是刚接触蓝牙模块的硬件新手，还是做App对接的技术负责人，这套工具链都应该够用了。

1. 蓝牙连接测试到底在测什么

1.1 别被“连不上”三个字带偏

说句实话，我接到的蓝牙问题里面，十个里有八个都只写着“连接不上”。但“连接不上”背后可能完全不一样：可能是模块压根没上电，可能是手机扫描不到广播，可能是配对弹窗没出现，也可能是连接两秒后就掉线。

所以我现在拿到蓝牙项目，第一件事就是先把“连接测试”拆成三个层面：

• 射频层：信号能不能被扫描到，RSSI是多少，距离多远会断。
• 协议栈层：配对、鉴权、加密、Service发现、MTU协商有没有成功。
• 应用层：数据能不能收发，收发完连接会不会异常断开。

这三个层面对应不同的测试工具。手机上用App，PC上用驱动和Wireshark，嵌入式模块就要配合串口和脚本去验证。如果一上来就盯着应用层改代码，大概率是空转。

1.2 功能、性能、兼容，三种测试别混着做

我还习惯把测试分成三类，因为选工具的时候侧重点完全不一样：

• 功能测试：连接、断开、重连、配对、解绑、重启后再连。这类测试用普通的蓝牙调试App就够了。
• 性能测试：重点是延迟、吞吐、掉线率、长时间稳定性。需要脚本去反复连接和收发数据，记录掉线次数。
• 兼容测试：同一套设备分别连接Android、iOS、Windows、Linux。每个系统对蓝牙的处理逻辑不太一样，尤其是iOS对经典蓝牙SPP的限制很严格，很容易在这里翻车。

搞清楚这三类测试，再看下面这些工具，心里就会有一个整体地图，不会东一榔头西一棒子。

2. 手机上的蓝牙测试App：最快出结果的一层

2.1 nRF Connect：我第一个安装的蓝牙调试工具

在手机端，我最常用的就是nRF Connect，它是Nordic官方出的，Google Play和App Store都能下。它最大的好处是能把蓝牙设备的Service、Characteristic、Descriptor全部列出来。

正常连接BLE设备后，nRF Connect会显示设备的Service UUID和每一个可读可写的Characteristic。我一般会用它来做三件事：

• 验证设备广播是不是正常。
• 连接后查看GATT表结构，确认自己固件里注册的Service有没有问题。
• 直接向Characteristic写入测试数据，或者订阅Notify，让设备主动上抛数据。

比如调试ESP32的BLE时，ESP32默认会创建一个Service，里面有一个可读写的Characteristic。你在nRF Connect里连接后，可以直接点“向上箭头”的按钮发送数据。如果ESP32端没收到，那就是数据通路断了，而不是App的问题。

2.2 国产调试助手和“小牛蓝牙调试助手”这类工具

除了nRF Connect，我还会装几个国产的蓝牙调试App，比如“BLE调试助手”“蓝牙调试助手”，包括很多网友提到的“小牛蓝牙调试助手”，这类工具对做硬件模块的人特别友好，因为它们通常直接集成了串口透传和AT指令发送功能。

比如测试HC-05、HC-06这类经典蓝牙模块时，很多App可以走蓝牙SPP通道，直接像串口一样发数据。你只要在App里选择模块名称，点击连接，然后把显示的输入框当成串口发送端，就能给模块发AT指令。

这里有个细节：Android上走经典蓝牙SPP需要App申请蓝牙权限，如果你发现App一直扫不到HC-05，先确认一下手机系统是否已经授权“附近设备”权限。iPhone上更麻烦，iOS对经典蓝牙SPP支持很差，很多SPP设备在iPhone上根本连不上，只能测试BLE设备。

2.3 用App快速定位HC-05/HC-06连接不上

凭我踩坑的经验，HC-05连不上，绝大多数是这三个原因：

1. 接线错误。HC-05的TX要接USB转TTL的RX，RX接TX，交叉接。很多人按“同名相连”接了，风扇似的狂接，结果自然没反应。
2. 没进AT模式。HC-05上电前，需要把EN引脚或者按键拉高，才能进入AT指令模式。如果不进AT模式，蓝牙可以正常被手机搜到，但串口发AT指令没有反应。
3. 波特率不匹配。老版HC-05默认波特率是9600，新版可能是38400。不要只试一个，多换几个波特率，尤其是看到模块有响应但全是乱码的时候。

HC-06相对简单一些，默认就能发AT指令，但“AT无响应”的问题也很常见。我遇到最多的情况是USB转TTL模块的电平不对，或者模块上电时序有问题。HC-06接了但指示灯不亮，就先量电压，看是不是3.3V还是5V供电没到位。

3. PC端和协议级测试：抓包才是排查问题的最终手段

有时候App显示连接成功了，但数据就是不对。这时候性能测试和排查真正底层的原因，PC端工具就派上用场了。

3.1 用Wireshark抓蓝牙包，怎么抓到关键信息

Wireshark主要用来抓网络包，但它的蓝牙部分能力一直被很多人忽视。实际上，Wireshark可以直接捕获蓝牙HCI数据，尤其当你用USB接口的蓝牙适配器时，抓包的人能直接看到设备之间的连接请求、断开原因、L2CAP通道建立情况，甚至能看到ATT协议的具体读写。

如果你用的是Windows笔记本，常见做法是安装Wireshark和USBPcap，然后在选择捕获接口时选对应的USB接口或者蓝牙HCI接口。捕获完成后，在过滤器里输入btl2cap或btatt，就能过滤出蓝牙逻辑链路和GATT协议的数据。

但Windows下抓包经常遇到一个问题：内置蓝牙适配器没法直接在Wireshark里抓到包。我后来学乖了，抓蓝牙包的时候干脆买一个USB的CSR蓝牙适配器，专门用来抓包，这样捕获接口就很稳定。很多团队测试时会用专用的蓝牙协议分析仪，但个人开发者或者小团队，用Wireshark加USB适配器已经够了。

3.2 驱动问题和“代码10”这类Windows经典坑

Windows蓝牙测试绕不开驱动问题。热词里很多人提到“brlink蓝牙驱动”“8852be蓝牙”，还有“win10蓝牙删除设备删不掉”“代码10 status_device_power_failure”，这些基本都是Windows蓝牙适配器或驱动的锅。

设备管理器里出现“该设备无法启动（代码10）”时，最常见的原因就是驱动报错，或者系统电源管理把蓝牙设备挂起来了。我一般的处理流程是：

1. 先拔掉USB蓝牙适配器，如果拔掉后设备管理器里设备消失，重新插上，看能不能恢复。
2. 打开设备管理器，找到蓝牙设备，右键卸载驱动，然后点“扫描检测硬件改动”让Windows重装一遍。
3. 到设备属性里找到“电源管理”，取消勾选“允许计算机关闭此设备以节约电源”。

在命令行下，还可以用Get-PnpDevice -Class Bluetooth查看蓝牙相关设备状态，用Disable-PnpDevice -InstanceId xxxx -Confirm:$false和Enable-PnpDevice快速实现禁用再启用。我自己写脚本做压力测试时，就喜欢用这种方式模拟“蓝牙模块突然消失又恢复”的场景。这个操作比拔USB要稳定得多。

至于“Win10蓝牙删除设备删不掉”，我碰到过几次，原因多半是因为后台某个服务还占用着蓝牙设备句柄。这时候先去设置里删除，删不掉就先关掉蓝牙开关，再打开，重新删。实在不行，就打开设备管理器，在“查看”菜单里勾选“显示隐藏的设备”，把灰掉的隐藏蓝牙设备一并卸载。

3.3 Linux下的bluetoothctl，调试效率远超图形界面

如果你在用Linux做开发，bluetoothctl是默认就要学会的命令行工具。它比任何图形界面都稳定。扫描、配对、连接、断开、查看设备信息，全在一个命令行里完成。

我常用的操作记录一下：

bluetoothctl scan on scan off pair 00:11:22:33:44:55 trust 00:11:22:33:44:55 connect 00:11:22:33:44:55 disconnect 00:11:22:33:44:55

如果你想测重连稳定性，可以写一个shell脚本，循环执行connect和disconnect，再配合日志时间戳。这个思路非常简单，但确实是模拟“设备频繁断连”最有效的方法之一。

4. 嵌入式模块场景：ESP32、BLE模块和自动化脚本

4.1 ESP32蓝牙和Wi-Fi共存，实测要注意什么

热词里有人问“ESP32蓝牙和wifi可以一起用吗”，我的答案是：可以，但要注意共存策略。ESP32的蓝牙和Wi-Fi共用同一根天线，硬件上并不是完全独立的两套射频系统，所以需要协议栈软件来做时间片调度。

在实测中，如果ESP32同时开Wi-Fi和BLE，Wi-Fi吞吐量比较大的时候，BLE连接会出现明显的延迟升高，甚至偶发断连。我踩过最明显的一次是：ESP32一边连着Wi-Fi传视频，一边用BLE被手机控制，结果手机在设备列表里能连上，但发指令经常失败。

解决办法是：

• 更新ESP32的固件到较新版本，老版本的共存调度确实更差。
• 确认初始化时调用了正确的蓝牙控制器配置，比如esp_bt_controller_mem_release，不要随意释放蓝牙需要的空间。
• 测试场景要分开：先单测BLE，再单测Wi-Fi，最后才测共存，不然出了问题无法定位。

4.2 用Python写自动化连接测试脚本

手机App适合功能验证，但压力测试就要靠脚本了。我会用Python写一些蓝牙自动化测试脚本，BLE用bleak库，经典蓝牙SPP用pybluez。这两个库一个管低功耗蓝牙，一个管经典蓝牙，基本覆盖了模块开发的大多数情况。

简单的BLE扫描示例：

import asyncio from bleak import BleakScanner async def scan(): devices = await BleakScanner.discover() for d in devices: print(d.address, d.name, d.rssi) asyncio.run(scan())

这个脚本能快速看到周围所有BLE设备的MAC地址、广播名称和信号强度RSSI。我在做蓝牙测距实验时，就是靠它连续记录RSSI变化，再手动移动到不同距离，最后画出一条信号衰减曲线。

如果要做完整的连接测试，可以用BleakClient连接设备，然后周期性地读写Characteristic，统计超时次数。这样一个晚上能跑几千次重连，比人工点点点靠谱多了。

4.3 蓝牙测距、水控器、键盘手柄这些场景怎么测

很多项目不只是连接模块，还涉及具体应用。比如热词里的“蓝牙水控器”“蓝牙台秤”“蓝牙键盘”“蓝牙手柄”，这些场景测试重点完全不同。

• 蓝牙水控器：一般用的是BLE或经典蓝牙透传，重点测控制指令的实时性和防丢失。因为水控器通常在公共区域，周围蓝牙设备很多，要特意在干扰较多的环境里做压力测试。
• 蓝牙台秤：主要测数据传输的完整性和稳定性。称重数据如果丢一个字节，可能重量就不对了。我一般会连续记录1000次称重结果，对比是否有异常跳变。
• 蓝牙键盘和手柄：重点测HID协议状态。键盘按下后能不能正常发送按键事件，手柄的摇杆数据能不能及时更新。如果连接后按键没反应，我通常会先用手机App连接看设备GATT表，确认HID报告映射没有错。

蓝牙测距是另一个常见需求，但我要泼一盆冷水：单纯用RSSI做测距，精度只能达到“大概几米”级别，别指望它能精确定位。因为RSSI受天线方向、人体遮挡、多径效应影响极大。如果你想做相对稳定的测距，至少要做多点校准，或者用带TOF功能的芯片。

5. 进阶协议场景与常见疑难杂症

5.1 A2DP切SCO模式，为什么声音会卡断

蓝牙音频设备测试中，最典型的一个难题就是A2DP和SCO切换。A2DP是高音质音乐播放通道，SCO是电话语音通道，两者在蓝牙协议栈里的优先级和带宽完全不一样。

我遇到过这样一个场景：设备连着手机放音乐，一切正常，一打电话或者打开录音App，声音就从立体声变成了明显发闷的单声道，甚至出现断断续续。这就是系统把蓝牙音频从A2DP切换到了SCO。

测试蓝牙音频设备时，不要只测播放音乐，一定要把通话和录音场景也跑一遍。在Android开发者选项里，可以查看当前蓝牙音频的编码格式、采样率和是否使用SCO路由。我在测耳机和音箱时，会开着音频循环播放，然后手动切换电话拨入、挂断，观察能不能自动切回A2DP。如果切不回来，那这个产品在真实使用场景里肯定会被用户骂。

5.2 iOS上的BLE连接问题：uni-app和Flutter开发者最容易翻车

很多前端开发者用uni-app或者Flutter做蓝牙功能，总会遇到iOS上的奇怪问题。

iOS的CoreBluetooth对BLE连接有严格的限制，比如你必须明确指定要连接设备的Service UUID，不能像Android那样“随便连一个”。很多人第一次在iOS上写BLE，扫描到了设备，但一连接就失败，就是因为没有在扫描参数里加serviceUUIDs。

另外，iOS后台模式下，如果不声明对应的后台蓝牙权限，App切到后台后连接很容易被挂起。Flutter的flutter_blue_plus和uni-app的BLE插件，底层走的都是CoreBluetooth，所以Android能跑通的代码，到iOS上不一定能跑通。

我的排错顺序是：先在nRF Connect上手动连接，看看能不能发现Service和Characteristic。如果nRF Connect能连上，App连不上，问题基本出在代码层。如果nRF Connect也连不上，那要么是设备广播数据不标准，要么是iOS缓存了旧设备信息，需要重启手机或删除蓝牙缓存。

5.3 不要忽略蓝牙芯片SDK和烧录工具的配合

测试过程中，工具链还会延伸到芯片级。热词里有“杰理蓝牙”“泰凌微蓝牙SDK”“diy杰理蓝牙芯片烧录器全攻略”等，这些其实是另一个层面的“连接测试工具”。

很多蓝牙模块出问题时，单纯看连接日志是不够的，你需要重新烧录固件来排除是硬件还是协议栈的bug。比如杰理芯片的DIY烧录器，用STC15F104复刻强制下载工具，这在网上有不少资料，原理是通过串口把固件烧进芯片。测试板卡不在手里的时候，有一把自己能控制的烧录器，调试效率完全不一样。

泰凌微的SDK里，操作Flash也是常见需求。连接不稳定时，我可能会改一些Flash参数，比如设备名称、广播间隔，重新烧录后再看效果。如果你没有烧录这一层面的储备，整个测试就只能停留在“用户可见的连不上”这个表象上，很难往深处查。

6. 实战排查清单与经验总结

6.1 一份可以直接抄的排查速查表

下面这张表是我现在做蓝牙连接测试时会直接对照的清单，分享出来，遇到问题可以先对号入座。

6.2 最后分享两个我自己用的土办法

第一个土办法是“看灯”。很多蓝牙模块状态和指示灯是强绑定的。HC-05上电后慢闪，代表可以被搜索；连接后常亮，代表链路已建立。如果模块灯在慢闪但手机扫不到，优先怀疑广播出了问题，而不是模块坏了。反过来，模块灯常亮，说明链路建立正常，如果数据传不了，问题大多在串口或应用层。

第二个土办法是“回环测试”。把USB转TTL模块的TX和RX直接短接，然后在电脑上用串口助手发数据，如果能收到自己发的数据，说明USB转TTL模块没问题。再把蓝牙模块接进去，把手机当作“透明通道”，手机发什么，电脑串口助手就应该收到什么。这样一层层剥洋葱，蓝牙问题不会跑到应用层去背锅。

6.3 工具是为排查服务的，最终还是要看链路

用过的工具再多，真正定位问题靠的还是逻辑。我现在做蓝牙测试时，心里永远装着一条链路：手机/PC应用层 —— 操作系统蓝牙协议栈 —— 蓝牙适配器 —— 空中射频 —— 模块协议栈 —— 模块串口/应用MCU。所有测试工具，要么是在验证某一层的状态，要么是在制造某一层的异常。

我自己长期用下来的核心工具组合其实很精简：nRF Connect、一个国产蓝牙调试App、Wireshark、Python的bleak脚本、Linux下的bluetoothctl，再加上一把靠谱的USB转TTL模块。这套工具组合可以覆盖从模块开发到App联调的绝大部分连接测试场景。将来如果遇到新的芯片平台，工具会有变化，但分层排查的思路不会变。