简介面向 Windows 平台 C 开发者的蓝牙串口通信示例工程解决通过虚拟串口连接蓝牙设备并实现双向数据收发的实际问题。工程覆盖虚拟串口机制、蓝牙应用程序接口调用、射频通信协议、设备发现与连接、创建设备文件句柄模拟串口、读写文件收发数据、多线程读写、错误处理与权限管理等关键技术点。资源包共94个文件压缩包约87.16MB包含Visual Studio工程文件、C源代码文件、编译中间文件、说明文档与效果截图目录结构清晰可直接打开工程查看代码并编译运行。目前已有401人浏览学习尤其适合需要快速上手Windows蓝牙串口通信开发的工程师以及想理解底层API调用与串口模拟原理的学习者。通过完整工程示例可掌握从设备扫描、连接、创建虚拟串口到数据交互的整套实现思路并了解权限申请与资源释放的注意事项便于后续集成到实际项目中。1. 虚拟串口连蓝牙为什么在 Windows 上成了默认解法很多 C 上位机项目里让电脑和一个蓝牙设备对话的实际落点并不是直接写蓝牙协议栈而是去打开一个 COM 口。Windows 在配对经典蓝牙设备时只要对方支持 SPP串口服务系统会自动为这条链路分配虚拟串口号。你接下来要做的就跟操作物理串口一样用 C 读写这个 COM 口这套方案成熟、稳定、好调试非常适合单片机、HC05 蓝牙模块这类设备的透传通信。不过这背后有几个必须搞清楚的机制否则你很容易被看起来是串口、实际上是无线链路的假象坑得不轻。2. 蓝牙 SPP 与虚拟串口的映射这条链路到底是怎么搭起来的2.1 为什么只有经典蓝牙能映射成 COM 口SPP 服务的宿命蓝牙协议栈里有一个专门给串口数据设计的服务叫 SPPSerial Port Profile。它的设计初衷就是在两个蓝牙设备之间建立一条虚拟的串行链路负责把你写入的字节流原样送到对端。物理层用 2.4GHz 射频上层不用管跳频、连接管理、错误重传这些细节——用 SPP 的用户只管往里灌数据。这里必须先分清两大体系只有经典蓝牙Classic Bluetooth支持 SPPBLE低功耗蓝牙4.0 之后的大部分现代设备是不支持的。BLE 走的是 GATT 服务和特征值Characteristic你要自己定义服务 UUID、读写特征还要处理 MTU 大小、通知订阅这些概念和打开串口直接发字节流完全是两码事。所以标题里的场景目标设备必须是支持经典蓝牙 SPP 的。常见的有 HC05、HC06 模块、杰理蓝牙方案做出来的透传串口设备还有一些老的蓝牙串口适配器。换个说法一块蓝牙模块之所以能变成无线串口就是因为它实现了 SPP 协议电脑才认它并在系统里给它分配 COM 口编号。如果模块只做了 BLE比如那些低功耗传感器、耳机音频控制通道电脑上不会出现任何串口这时候硬写串口程序是通不了的得改走 GATT 方向。2.2 Windows 蓝牙栈如何分配串口号入站口与出站口Windows 自带微软蓝牙栈配对流程由系统服务管理。当你把蓝牙设备和电脑配对成功后系统会向设备发起 SDP 服务发现Service Discovery Protocol看看对方有没有暴露 SPP 服务。如果有就为这个服务生成一个虚拟串口设备并分配 COM 号。实际在使用中会有两种情况设备管理器里经常能看到两个口分别叫入站和出站。入站口Incoming面向对方设备主动连电脑的场景出站口Outgoing面向电脑主动连对方设备的场景。以 HC05 模块为例把模块设成从机模式、电脑从设置里点击连接按钮时走的是出站口如果你把模块设成主模式、让模块扫到电脑并发起连接那么数据会走进站口。两个口分别对应不同的连接方向你 C 程序要打开的是和实际连接方向匹配的那一个。设备管理器里看到这两个设备名通常是标准串行 over Bluetooth link旁边括号里带着 COM 号。这里有个容易搞混的地方你不用两个口都打开只打开当前连接方向对应那一个就够了。另一个口在没有对端主动连/被连的时候是空闲的打开它会直接报错或者无数据。2.3 虚拟串口和物理串口的三个关键差异第一DTR、RTS 这类调制解调器控制信号在蓝牙虚拟串口上没有实际硬件对应物。物理串口用这些线做流控和握手蓝牙链路里没有这些线的概念。你调用 EscapeCommFunction 去拉高 DTR 只是让驱动发了一个逻辑状态对端模块根本感知不到所以别指望用 DTR/RTS 唤醒对端设备。第二波特率在这里是一个名义值它不直接影响射频速率。物理串口设错波特率会导致乱码但蓝牙虚拟串口上你把波特率从 9600 改成 115200数据链路本身照样能通因为这个波特率只是驱动层的一个参数。第三也是最本质的底层是一条射频链路。物理串口线缆只要不断、电平不出问题字节不会丢蓝牙链路受距离、遮挡、同频干扰影响会出现丢包、延迟抖动、甚至短暂断连后自动重连。你的程序必须把链路随时可能不完美当成默认前提来设计不能像对待物理串口那样裸奔。3. 让 C 打开蓝牙虚拟串口从配对到收发的最小工程3.1 配对与确认 COM 号设备管理器里先看清两个口在写代码之前先把蓝牙对好。以 Windows 10/11 为例打开设置→蓝牙和其他设备点添加设备设备处于可发现模式时列表里会出现它的名字。HC05 这类模块要注意一个坑不是上电就能被发现的通常需要按住模块上的按键再上电进入 AT 命令模式或配对模式指示灯慢闪时才能被搜到。配对码一般是 1234 或 0000。配对成功后别急着写代码先打开设备管理器确认 COM 号。操作路径WinX → 设备管理器 → 展开端口COM 和 LPT你会看到类似标准串行 over Bluetooth link (COM7)这样的条目。如果设备管理器里只出现了一个口说明对端模块只暴露了一个方向的服务如果出现两个就是上面说的入站加出站。建议你在这个环节就记下两个口的编号并测试一下哪个口能真正通。测试方法把模块和电脑配对后在 Windows 的蓝牙设置里找到已配对设备点连接如果状态变成已连接那么对应的就是出站口。C 程序里就打开这个出站口。如果你把模块配置成主模式由它主动连电脑那就打开入站口。大多数透传模块默认是从机模式所以实际用的通常都是出站口。3.2 C 打开串口CreateFile 与 DCB 参数必须这么设确认好 COM 号后写代码就是经典的 Windows 串口三件套CreateFile 打开句柄、GetCommState/SetCommState 设置参数、SetCommTimeouts 设置超时。下面是能直接编译的最小片段#include windows.h #include iostream HANDLE OpenBluetoothCom(const char* comName) { // 虚拟串口路径建议用 \\\\.\\ 前缀兼容 COM10 及以上的编号 char path[64]; snprintf(path, sizeof(path), \\\\.\\%s, comName); HANDLE hCom CreateFileA( path, // 设备路径例如 COM7 GENERIC_READ | GENERIC_WRITE, // 读写都要 0, // 独占打开不共享 nullptr, // 默认安全描述符 OPEN_EXISTING, // 打开已存在的设备 FILE_ATTRIBUTE_NORMAL, // 同步模式后面再讲异步 nullptr); if (hCom INVALID_HANDLE_VALUE) { DWORD err GetLastError(); // err 2: 找不到指定文件说明 COM 号不对或设备未就绪 // err 5: 拒绝访问说明串口正被另一个程序占用 std::cerr CreateFile failed, error err std::endl; return INVALID_HANDLE_VALUE; } // 读取当前 DCB 配置再修改需要的字段 DCB dcb{}; dcb.DCBlength sizeof(DCB); if (!GetCommState(hCom, dcb)) { CloseHandle(hCom); return INVALID_HANDLE_VALUE; } dcb.BaudRate CBR_9600; // 这个值只影响上层逻辑不是物理射频速率 dcb.ByteSize 8; dcb.Parity NOPARITY; dcb.StopBits ONESTOPBIT; dcb.fBinary TRUE; // 二进制模式必须为 TRUE dcb.fParity FALSE; // 蓝牙虚拟串口没有物理流控线全部禁用 dcb.fOutxCtsFlow FALSE; dcb.fOutxDsrFlow FALSE; dcb.fDtrControl DTR_CONTROL_DISABLE; dcb.fRtsControl RTS_CONTROL_DISABLE; dcb.fOutX FALSE; dcb.fInX FALSE; if (!SetCommState(hCom, dcb)) { CloseHandle(hCom); return INVALID_HANDLE_VALUE; } return hCom; }这里逐项说清楚参数意义。CreateFile 的第三个参数建议传 0也就是独占串口这样能避免其他程序同时打开这个虚拟串口造成数据错乱。第五个参数 OPEN_EXISTING 是必须的虚拟串口不是创建的设备只能用 OPEN_EXISTING 打开。DCB 里我重点把 DTR 和 RTS 流控全部禁用原因在 2.3 小节已经说了蓝牙链路里没有这两根线的实物开着反而可能让驱动层多做无意义的信号协商。需要注意的是BaudRate 这里我写的 9600 更多是规矩层面的选择。如果你的模块侧 UART 波特率配的是 115200这里最好跟模块侧保持一致。虽然前面说了蓝牙链路本身不受这个值影响但很多驱动和设备侧会做波特率匹配检查不一致时某些厂商的驱动会拒绝把数据往下送。最省事的做法是模块用什么波特率DCB 就填什么。3.3 读写循环与超时策略别让 ReadFile 把程序卡死打开句柄之后最常翻车的点就是 ReadFile。如果你不做任何超时设置ReadFile 会阻塞到有数据为止而蓝牙链路在空闲时根本没有数据你的程序就挂在读取那一步连心跳都发不出去。解决办法是设置 COMMTIMEOUTS让读取在没有数据时快速返回。void ConfigureTimeouts(HANDLE hCom) { COMMTIMEOUTS timeouts{}; // 两次字节到达之间的最大间隔50ms 内没有新字节就返回 timeouts.ReadIntervalTimeout 50; // 下面的乘数和常数共同决定总超时时间 timeouts.ReadTotalTimeoutMultiplier 10; timeouts.ReadTotalTimeoutConstant 100; timeouts.WriteTotalTimeoutMultiplier 10; timeouts.WriteTotalTimeoutConstant 200; SetCommTimeouts(hCom, timeouts); }这三个超时值的配合逻辑是ReadFile 调用期间只要在读间隔超时或总超时二者的任一条件满足就返回。ReadIntervalTimeout 50 意味着如果连续两个字节之间间隔超过 50ms本次读取就结束ReadTotalTimeoutConstant 100 意味着即使一直在收到字节累计等待 100ms 也会强制返回。这样设计的好处是蓝牙链路偶尔抖动时你的程序不至于在一个 ReadFile 上困死而是能周期性地回到循环里去处理超时、心跳、重连等事务。在实际项目里我一般会起一个专门的接收线程主线程做发送和业务逻辑。线程里用一个循环持续 ReadFile每批次拿到的字节丢给协议解析层处理。核心代码类似volatile bool g_running true; DWORD WINAPI ReadThreadProc(LPVOID param) { HANDLE hCom (HANDLE)param; BYTE buffer[256]; while (g_running) { DWORD bytesRead 0; BOOL ok ReadFile(hCom, buffer, sizeof(buffer), bytesRead, nullptr); if (!ok) { DWORD err GetLastError(); // 常见的 ERROR_SEM_TIMEOUT(121) 表示超时返回不是致命错误 if (err ERROR_SEM_TIMEOUT) { continue; } // 其他错误比如 ERROR_BROKEN_PIPE(109) 表示连接断开了 break; } if (bytesRead 0) { HandleRxData(buffer, bytesRead); } } return 0; }这里有两个容易被新手误判的点。第一ReadFile 返回 FALSE 并不代表链路挂了超时返回也是 FALSE错误码是 ERROR_SEM_TIMEOUT121要区分对待。第二蓝牙虚拟串口在一端断开时ReadFile 可能返回 ERROR_BROKEN_PIPE109或 ERROR_DEVICE_REMOVED1617这两种情况才需要做重连或通知上层处理。我习惯在循环里把 121 当正常情况跳过其他错误都视为链路异常从而驱动重连逻辑。4. 通信协议与可靠性参数虚拟串口不是普通串口4.1 帧格式设计帧头、长度、校验与粘包拆分很多直接用串口的人会犯一个错误字节来了就逐字节处理或者按固定长度读取结果对端设备发的是一帧 18 字节的命令程序却按 4 字节一段去解析数据全乱。原因在于串口是无消息边界的字节流蓝牙虚拟串口也一样——它只保证字节顺序不保证你发一帧我收一帧。上层必须自己定义帧格式来解决粘包和半包问题。我常用的一个轻量帧格式是帧头 2 字节0xAA 0x55、类型 1 字节、负载长度 2 字节小端、负载数据 N 字节、CRC8 校验 1 字节。最小帧长是 7 字节最大取决于你设定的负载上限一般 255 或 1024。CRC8 可以用查表法也可以用简单的多项式累加。帧头用 0xAA55 是为了让它有足够特征不会和正常数据混淆。接收端的拆包逻辑是维护一个累计缓冲区每次收到新字节就追加然后循环在缓冲区里找帧头、取长度、判断完整性std::vectorBYTE rxBuffer; void HandleRxData(BYTE* data, DWORD len) { // 1. 追加新数据 rxBuffer.insert(rxBuffer.end(), data, data len); // 2. 循环拆帧 while (rxBuffer.size() 7) { // 至少要有帧头长度校验 // 找帧头 if (rxBuffer[0] ! 0xAA || rxBuffer[1] ! 0x55) { rxBuffer.erase(rxBuffer.begin()); // 错位则逐字节丢弃 continue; } // 解析负载长度小端 int payloadLen rxBuffer[2] | (rxBuffer[3] 8); int totalLen 2 1 2 payloadLen 1; // 帧头类型长度负载CRC if (rxBuffer.size() totalLen) { break; // 帧数据还没收全等更多数据 } // 校验 CRC8这里用简单累加实际可用查表 BYTE crc CalcCRC8(rxBuffer.data(), totalLen - 1); if (crc ! rxBuffer[totalLen - 1]) { // 校验失败说明这一帧坏了丢弃帧头继续找下一帧 rxBuffer.erase(rxBuffer.begin()); continue; } // 取出完整一帧 std::vectorBYTE frame(rxBuffer.begin(), rxBuffer.begin() totalLen); ProcessFrame(frame.data(), frame.size()); // 移除已处理的数据 rxBuffer.erase(rxBuffer.begin(), rxBuffer.begin() totalLen); } }这个拆包逻辑有几个关键点。第一错位时逐字节丢弃而不是直接清空缓冲区是为了从错误数据里重新同步出正确帧。第二break条件处理的是半包——帧还没完整到达时必须等待下一批数据而不是把这段残缺数据丢掉。第三CRC 失败时丢弃的是当前帧头的第 0 字节让下一帧有机会被正确解析。这样整体下来无论对端是一次性把整帧发过来还是分成几个小块发接收端都能正确还原出完整帧。发送端就简单多了按帧格式把数据填入字节流计算 CRC然后一次 WriteFile 发送。但注意一次 WriteFile 未必能把所有字节写完要检查返回的 bytesWritten 是否等于你期望发送的长度如果不等于就补发剩余部分。4.2 握手与重发让虚拟串口从能通变成能用帧格式解决的是数据怎么组织的问题但蓝牙链路天生会有丢帧和延迟抖动。要在这条链路上做一个可靠的上位机通信必须在帧之上再加一层握手与重发机制。我的做法是三层应用层发命令帧等待对端回 ACK 帧如果 500ms 内没收到 ACK重发同一帧连续重发 3 次仍无 ACK就判定链路异常向上层回调一个连接失败事件触发重连流程。握手帧本身也走同一个帧格式类型字段里区分0x01 是数据命令、0x02 是 ACK、0x03 是 NAK。对端收到命令帧后不管处理结果如何先回一个 ACK 表示收到处理完逻辑问题再回结果帧。这种先确认再处理的握手段位能帮你快速区分丢包和业务错误——如果连 ACK 都没收到问题大概率在链路上收到 ACK 但没有结果帧问题才可能在对端业务逻辑里。重发参数要按蓝牙链路的实际往返时延来设。经典蓝牙 SPP 在正常距离下的往返时延通常在 20~100ms 之间我把超时定为 500ms 是一个比较保守的值。如果你的设备是低功耗蓝牙透传模块往返可能到 200ms 甚至更高超时就得放宽到 800ms~1s。这个值不能拍脑袋填应该在链路最差条件下实测后微调。4.3 波特率、缓冲区与流控参数怎么调虚拟串口场景下真正需要调的串口参数其实只有两个方向一是前面 DCB 里的 BaudRate 要与模块侧 UART 一致二是接收缓冲区的大小。很多 Windows 串口驱动会设置一个内部缓冲比如 4096 字节。如果你的上位机接收线程不够及时数据涌入导致内部缓冲溢出就会出现丢尾巴的现象——帧头收了一部分后面的字节丢了。做法是在 SetCommState 之后调用 SetupComm设定输入输出缓冲区大小SetupComm(hCom, 8192, 8192); // 输入输出缓冲各 8KB具体设多大取决于你的负载大小和链路速率。如果一帧最多 1KB缓冲至少是最大帧的 8 倍以上这样可以容忍接收线程被调度延迟两个周期。另外Windows 蓝牙栈内部还有一个射频层的缓冲这个我们改不了所以只能保证自己的代码及时读走数据不给驱动层添堵。至于流控参数虚拟串口场景下我全部保持禁用。前面 2.3 小节已经解释过DTR/RTS 在蓝牙链路里是逻辑上的摆设。但有一种特殊情况有些 USB 蓝牙适配器的驱动会在底层模拟 RTS 信号用来实现远端设备的流控。如果对端模块是那种带 CTS/RTS 引脚的你可能需要在模块侧把流控关掉让模块不管 CTS 状态否则会出现模块不回数据的诡异现象。5. 避坑蓝牙虚拟串口最常见的 5 个翻车现场5.1 设备管理器里根本看不到虚拟串口现象蓝牙设备配对成功但设备管理器端口COM 和 LPT下面一条蓝牙串口都没有。原因最常见的有三种。一是你配对的设备是 BLE 设备它只实现了 GATT 服务没有 SPPWindows 自然不分配串口。二是设备虽然支持 SPP但配对时被系统识别成了其他设备类型比如音频设备或输入设备SDP 服务发现没有正确返回串口服务。三是系统蓝牙栈被第三方驱动覆盖了比如装了某些增强型蓝牙驱动后微软自带的蓝牙虚拟串口服务被替换。解决先用蓝牙设置里看设备类型如果是耳机/键盘/音频这类基本可以确认它没有走 SPP。再用bluetooth device这种硬件 ID 在设备管理器里反向查找。如果确实支持 SPP 但没出串口卸载设备再重新配对一次。如果系统蓝牙栈被第三方驱动覆盖去设备管理器里把蓝牙枚举设备回滚到系统自带驱动或者卸载第三方驱动后重启电脑再配对。5.2 COM 口存在但 CreateFile 返回 INVALID_HANDLE_VALUE现象设备管理器里明确看到标准串行 over Bluetooth link (COM7)但 C 程序打开 COM7 时拿到无效句柄GetLastError 返回 5拒绝访问或 2找不到文件。原因error 5 通常是串口被另一个程序占用常见的是你开着串口调试助手没关或者上一次程序退出时没有 CloseHandle句柄泄漏。error 2 比较隐蔽你在设备管理器看到的 COM 号和你代码里写的 COM 号不一致比如系统里同时存在 COM7 和 COM9你写的是 COM7但蓝牙口实际上是 COM9。解决打开设备管理器确认实际 COM 号逐一排除串口号占用。代码层面在 CreateFile 前用 QueryDosDevice 枚举一下系统当前所有 COM 端口打印出来对比。另外注意COM 号大于 9 时必须用\\.\前缀这个前面代码里已经写了。如果还有问题最直接的办法是重启蓝牙设备让系统重新分配 COM 号或者在设备管理器里手动修改 COM 号到一个没冲突的编号。5.3 串口能打开但收发完全没有数据现象CreateFile 成功、SetCommState 成功但 WriteFile 返回成功却收不到任何字节ReadFile 永远超时。原因最常见的是打开了错误的 COM 号。前面说过会有入站出站两个口你打开的那个口对应的连接方向不对数据根本没走这个口。另一种可能是对端模块虽然配对成功但蓝牙底层的 SPP 连接并没有真正建立——注意配对和连接是两回事Windows 显示已配对并不代表 SPP 通道已经连上了。解决程序里先不做任何读写用 Windows 自带蓝牙设置确认已连接状态如果是手动连接点连接后再启动程序。代码层面在打开虚拟串口后先发送一个空字节或者查询指令然后用串口工具同时监听对端一侧确认数据是否真的从蓝牙链路发出。如果对端是 HC05用 USB-TTL 接模块的 TTL 串口引脚开一个串口调试助手看着两边一对照就知道数据卡在哪个环节了。这个排查法我用了很多年效率最高。5.4 通信跑几十秒就断需要重连后才恢复现象连接建立后前面几帧数据正常几十秒后 WriteFile 返回成功但对方不再回包ReadFile 也一直超时。重连后又能正常几十秒。原因两种典型情况。一是蓝牙链路进入了保持模式或休眠模式。很多蓝牙适配器和模块在空闲一段时间后会自动降功耗SPP 链路还挂着但数据传输被挂起了。二是环境干扰比如 2.4GHz 频段信号拥挤、电脑和模块之间有金属遮挡导致信噪比恶化蓝牙基带反复重传失败后把连接挂起。解决软件层面做周期性心跳我一般每 5 秒发一个空命令帧让链路保持活跃。如果你的设备不允许频繁发命令可以考虑在空闲时发 1 字节的 0x00 作为链路保活但必须和对端约定好让它识别并忽略这个字节。硬件层面把蓝牙适配器用 USB 延长线拉到桌面上拉开天线距离尽量远离路由器和其他 2.4GHz 设备。如果模块支持把蓝牙发射功率调高一些或者检查模块天线的焊接。5.5 安装了第三方虚拟串口工具后蓝牙 COM 口消失现象原本能用的蓝牙虚拟串口突然从设备管理器里消失或者打开时报错而之前你装过 com0com 之类的虚拟串口工具。原因第三方虚拟串口工具会注册自己的驱动和串口枚举逻辑有些版本在安装时会和 Windows 蓝牙枚举机制产生冲突导致标准串行 over Bluetooth link设备被挤掉或者 COM 号分配错乱。解决先卸载第三方虚拟串口工具然后到设备管理器里把蓝牙设备卸载再扫描检测硬件改动让系统重新枚举蓝牙设备。如果还不恢复去服务里确认 Bluetooth Support Service 正在运行并设为自动启动。更简单的临时方案用 Windows 自带的添加蓝牙设备流程重新配对一次绝大多数情况配对后虚拟串口就回来了。这个教训是做蓝牙虚拟串口开发的机器上尽量别再装其他虚拟串口工具除非你很清楚它们不会动蓝牙栈。6. 进阶把整条链路做成可验证、可监控的工程6.1 回环验证在程序里做一次自发自收的信心测试当你把代码写完面临的问题往往是通了但我不确定是不是真通。我习惯在程序启动阶段加一个回环自检向对端设备发送一个特殊的回环命令帧类型用 0x0F对端收到后原样返回一帧数据程序收到回环响应后把帧类型字段解析出来确认对端固件和链路都正常才开始业务通信。如果对端设备是你在开发的那就在设备侧单独做一个回环处理函数收到 0x0F 类型就复制负载原样回发。若对端是不可修改的现成设备就用 HC05 的 AT 模式手动测试把模块设成回环模式部分 AT 固件支持 ATUART 透传测试或者直接把模块串口引脚接到 USB-TTL 上从 PC 端发数据看 TTL 侧是否收到。回环通过的意义在于它把链路问题和协议问题划了一道清晰的界线之后任何故障排查你都可以先从这条界线两侧下手。6.2 日志把玄学掉线变成可定位的现场蓝牙链路最大的痛点就是难以复现。我强烈建议从第一版程序开始就带一个可以落盘的日志系统记录每一帧的收发时间毫秒精度、方向、帧类型、数据长度、CRC 结果、以及每次连接和断开的事件。时间戳用std::chrono::steady_clock来取不用time()因为你要的是相对时延而不是墙钟时间。遇到掉线问题先看日志里掉线前后 10 秒的收发序列。如果连续多帧发出去后收不到 ACK链路就开始退化如果没有任何发送记录直接掉线问题可能出在射频环境或驱动层。这种日志我保存为按小时滚动的 CSV 文件每行记录完整十六进制帧内容后面用 Python 一行就能统计丢帧率、平均时延和确认成功率。有这些数据在手上跟硬件工程师对接时就有底气——你能明确指着日志说第 14 分 32 秒开始连续丢了 4 帧而不是说一句我感觉不太稳定。说实话我早期在这条链路上翻过不少车最大的教训就是别把蓝牙虚拟串口当成物理串口来信任。物理串口坏了你会第一时间怀疑硬件蓝牙虚拟串口出问题光是软件还是射频的问题就能排查一整天。把协议、握手、超时、日志全部补上之后这个方案反而成了我项目里最省心的部分。希望帮到你。本文还有配套的精品资源点击获取
