企业官网建设流程全解析

做嵌入式或者做移动端开发的人，几乎都会在同一块板子上同时碰到蓝牙和WiFi这两个东西。它们看起来是两个完全独立的子系统——驱动分开、协议栈分开、连调试工具都不是同一拨人写的——但只要产品需求里出现"两个同时开"，麻烦立刻就来了：WiFi吞吐掉一半、蓝牙音频开始断续、扫描扫不到设备、连上了过一会儿又掉。更让人头疼的是，这两套东西还挤在同一个2.4GHz频段里抢地盘，射频前端甚至可能共用一条天线。

这篇总结不谈某一个具体的SDK怎么调API，而是把蓝牙和WiFi放在一起，从射频层、协议栈层、驱动层一路讲到模块选型和移动端开发，把"它们为什么会互相干扰""调试时该从哪一层入手""模块怎么选"这几件事串成一条线。内容覆盖BLE与经典蓝牙的差异、协议栈分层、连接建立时序、A2DP与SCO切换、WiFi驱动与固件的关系、Ubuntu下WiFi图标消失的排查、TX校准、HC-05/HC-06类透传模块的AT调试、ESP32蓝牙与WiFi共存、蓝牙测距精度以及Android/iOS/Flutter/uni-app的BLE开发差异。适合刚上手无线开发的工程师，也适合被"连不上、扫不到、掉线"折磨过的老手拿去对着排错。

需要说明的是，涉及未经授权访问他人网络的内容不在讨论范围内，本文只讲自建设备、自建网络和自有模块范围内的技术问题。

1. 挤在同一条2.4GHz走廊里的两套系统

先说一个我早期踩过的坑。有一次做一个带WiFi上传的蓝牙称重设备，单独测蓝牙一切正常，单独测WiFi也一切正常，两个一起开会发现蓝牙连接间隔一到20ms就开始丢包，称重数据偶尔卡住半秒。当时第一反应是蓝牙协议栈有bug，换了两个模块、刷了三版固件，最后发现问题根本不在软件层——是射频层的时间片被抢了。从那以后我养成了一个习惯：只要蓝牙和WiFi要共存，先算射频账，再谈代码。

1.1 频谱资源的物理边界：为什么偏偏是2.4GHz

2.4GHz ISM频段的范围是2.400GHz到2.4835GHz，总带宽83.5MHz。这个频段在全球大多数地区属于免许可使用，不需要申请频谱牌照，所以WiFi、蓝牙、无线鼠标、微波炉、部分无绳电话全挤在这里。免费是有代价的，代价就是拥挤。

WiFi在2.4GHz上的划分方式是把83.5MHz切成若干20MHz宽的信道，国内可用1到13信道，中心频率从2412MHz开始每5MHz递增。这里有个关键点：相邻信道之间只隔5MHz，而单个信道占20MHz，所以1、2、3信道是互相重叠的，真正互不干扰的只有1、6、11这一组。很多人调WiFi的时候喜欢随手选个信道，选到3或者9，结果和邻居的1、6撞在一起，速率掉一半还找不到原因。

BLE的划分方式完全不同。它把2.4GHz切成40个信道，每个信道2MHz宽，编号0到39。其中37、38、39三个是广播信道，中心频率分别在2402MHz、2426MHz、2480MHz，剩下的37个是数据信道。经典蓝牙则是79个信道，每个1MHz，靠快速跳频在整个频段里游走。

这三个数字放在一起就能看出问题：BLE的广播信道恰好落在WiFi的1信道（2412MHz）和6信道（2437MHz）附近，也靠近11信道（2462MHz）。也就是说，设备在广播阶段被WiFi干扰的概率，比在数据阶段要高。

1.2 蓝牙跳频和WiFi OFDM的占道方式根本不是一回事

理解干扰，关键在于理解两种技术"占道"的方式不一样。

WiFi用的是OFDM，一旦开始发数据，它会在选定的那个20MHz（或40/80MHz）信道上持续发送，直到这一帧发完。它相当于在一条街上长期占道施工，邻居只能绕行。蓝牙用的是跳频，BLE在每个连接事件里换一个信道，经典蓝牙跳得更快，每秒上千次。它相当于在整条街上不停地换位置停车，尽量避开正在施工的路段。

这个差异决定了两种技术受损的样子完全不同。蓝牙包撞上WiFi帧，后果是这一个包收不到，链路层会在下一个连接事件重传，表现为偶发的延迟抖动；WiFi帧撞上蓝牙包，后果是CRC校验失败，触发退避重传，表现为吞吐下降。所以你在抓包的时候会看到两种典型现象：蓝牙侧是个别连接的间隔时间突然拉长，WiFi侧是重传率上升、实际吞吐低于协商速率。

BLE从4.1开始支持自适应跳频（AFH），它会维护一张信道质量图，把被占用严重的信道标记出来不再使用。但这个机制起作用需要时间，而且只能避开持续干扰，对突发干扰效果有限。实际项目里如果你知道WiFi固定在某个信道，可以主动把BLE的广播信道避开对应的频率，代价是广播被收到的概率下降，需要用更长的广播间隔来补偿。

1.3 单芯片共存：一套射频怎么被两个协议栈分着用

现在主流的方案是WiFi和蓝牙做在同一颗芯片上，ESP32、很多手机SoC、部分网关芯片都是这种结构。芯片里只有一个2.4GHz射频前端和一条天线，WiFi和蓝牙不能真的同时发射，只能靠硬件仲裁做时间分片。

以ESP32为例，内部的共存机制大致是这样工作的：WiFi和蓝牙控制器各自向一个仲裁器申请射频使用权，仲裁器根据优先级和时间片分配。WiFi的Beacon、ACK这类时序敏感的操作优先级最高，蓝牙的连接事件可以在空闲窗口里插入。这套机制在ESP-IDF里通过菜单配置开关，关键项包括软件共存开关和共存优先级策略。

# ESP-IDF 中与共存相关的典型配置项 CONFIG_ESP_COEX_SW_COEXIST_ENABLE=y CONFIG_ESP_COEX_PREFER_WIFI=y CONFIG_BT_ENABLED=y CONFIG_BT_BLE_ENABLED=y

实际测下来，WiFi和BLE同时开，WiFi的TCP吞吐大概会掉到单独运行时的三到五成，具体取决于WiFi的业务负载和BLE的连接间隔设置。我的经验做法是：如果BLE只是传少量状态数据，把连接间隔设到50ms以上，从机延迟给几个周期，蓝牙对WiFi的侵占就很小；如果BLE要做实时数据传输，比如音频或者高频传感器，那就要么接受WiFi降速，要么把两个功能拆到两颗芯片上。

还有一点容易被忽略：共存不只是射频时间的问题，还有内存和中断的问题。ESP32上开BLE约占50到70KB的RAM，加上WiFi协议栈本身的占用，如果项目里还跑着HTTP服务器和文件系统，堆内存会很紧张，表现为随机重启。这种情况要优先看堆剩余量，而不是怀疑共存机制坏了。

2. 蓝牙协议栈拆开看：从HCI到Profile各自管什么

刚开始接触蓝牙的人最容易晕的不是代码，而是名词。"GATT是什么""L2CAP在哪一层""HCI到底是谁和谁之间的接口"，这些问题在文档里都能查到，但很少有人把它们串成一张能用的图。我在带新人的时候习惯先让他们把分层模型记住，因为后面所有的调试动作，本质都是在判断问题出在哪一层。

2.1 分层模型与常见缩写的对应关系

蓝牙协议栈大致可以分成三块：主机（Host）、主机控制器接口（HCI）、控制器（Controller）。主机跑在应用处理器上，控制器通常在芯片内部或者独立的模块里，HCI是两者之间的通道，可以是UART、USB或者SDIO。

BLE的分层从上往下大致是这样：

经典蓝牙的分层不一样，它在L2CAP之上走的是RFCOMM（串口仿真）和SDP（服务发现），音频走AVDTP加A2DP，通话控制走HFP和AT命令。所以如果你在外围设备里看到"通过RFCOMM传数据"，那基本可以确定是对经典蓝牙的串口透传，不是BLE。

调试验证的方法和这个分层完全对应。用hciconfig或者bluetoothctl看到的是控制器和GAP层的信息；用nRF Connect这类工具看到的是GATT层的服务结构；用抓包器抓空中包看到的是Link Layer和PHY层。哪一层出问题，就去哪一层找工具。我见过不少人拿着GATT层的日志去分析连接掉线，那基本是在做无用功，掉线往往是Link Layer的监督超时或者射频干扰。

2.2 经典蓝牙与BLE在链路层就分道扬镳

这两种技术名字里都带蓝牙，但它们在链路层的差异大到几乎可以当作两种技术。我在选型的时候，会拿四个指标来快速判断该用哪个：

选型的判断逻辑很简单：要传音频或者要传大块数据，选经典蓝牙；要靠电池撑几个月、传的数据是几十字节的状态量，选BLE。真正纠结的场景是既想省电又要音频，这时候通常的做法是BLE负责连接管理和控制，音频走经典蓝牙，也就是所谓的双模方案，代价是芯片成本和功耗都上去了。

2.3 BLE连接建立的完整时序拆解

BLE从"设备存在"到"能收到数据"，中间要经过一串标准动作。很多人调试BLE卡住，就是因为不清楚这些动作的先后顺序，导致在错误的阶段找问题。

第一步是广播。设备周期性在37、38、39三个信道轮流发送广播包，包里包含设备地址、广播类型、可选的名称和服务UUID。广播间隔可以设20ms到10.24s，间隔越短被发现越快，功耗越高。

第二步是扫描。中央设备在自己的扫描窗口里监听这三个信道，收到广播后解析内容。这里有个容易踩的点：扫描窗口和扫描间隔的比例决定了扫描占空比，如果占空比设得很低，可能会漏掉部分广播包。

第三步是发起连接。中央设备在收到广播后，向该设备发送连接请求，请求里包含连接间隔、从机延迟、监督超时这三个关键参数。从这一刻起双方进入连接状态。

第四步是连接事件。之后每个连接周期内，主从双方在约定的信道上交互一次。从机只能在主机的轮询下应答，这是BLE的调度规则。

第五步是服务发现和订阅。连接建立不等于能收数据，主机要先读取从机的服务列表，找到目标特征值，然后写入CCCD描述符来订阅通知。

连接间隔的取值要按业务定。7.5ms到4s的范围里，10ms以下适合实时控制，50ms到200ms适合绝大多数传感器上报，1s以上适合极低功耗场景。监督超时一般设成连接间隔的几倍，设得太小会因为偶发丢包直接断连，设得太大则在设备真的离开后很久才感知到掉线。

2.4 A2DP、SCO与HFP：音频链路切换时为什么会有一声咔哒

用蓝牙耳机听歌的时候，来一个电话，音乐会停顿一下然后音质变得有点闷，挂断后又切回来。这个过程中发生的就是A2DP和SCO之间的切换。

A2DP负责高质量音频播放，走的是ACL链路，编码常用SBC、AAC，速率较高、延迟较大。通话走的是SCO或者eSCO链路，这是一条预留时隙的同步通道，带宽固定，编码常用CVSD或者mSBC，语音质量优先，速率低。

切换的过程是这样的：HFP检测到来电，通过AT命令协商，双方暂停A2DP的数据流，在控制器里建立SCO链路。因为这两条链路的时隙分配方式不同，SCO需要占用固定周期的一对时隙，射频调度要重新排布，所以会出现几百毫秒到一两秒的音频中断。音质变闷的原因是编码从SBC切到了CVSD，采样率从44.1kHz降到了8kHz。

调这类问题的时候，看的是HCI日志里的同步连接建立事件和编码协商结果，而不是看应用层代码。如果项目里自己做语音链路，要注意SCO建立过程中WiFi如果有大流量传输，失败的几率会明显上升，因为射频调度被抢了。

3. WiFi从驱动到射频：一次连接背后发生了什么

蓝牙那套是模块化设计，大部分时候你面对的是模块和协议栈；WiFi这边不一样，尤其在Linux桌面环境下，你会直接面对内核驱动、固件文件和射频校准这一整条链路。很多"网卡装了但没WiFi图标"的问题，根源都不在网卡本身，而在中间某一环没对上。

3.1 驱动、固件、内核模块的铁三角关系

一块WiFi网卡要能用，至少需要三样东西同时到位：内核里有对应的驱动模块、文件系统里有匹配的固件文件、系统识别到设备节点。

以常见的Realtek RTL8852BE这块WiFi 6网卡为例，它对应的驱动是rtw89。这个驱动从Linux 5.16开始才逐步进入主线内核，而Ubuntu 22.04早期版本默认内核是5.15，所以插上之后设备能识别到，但没有网络接口，ip link里看不到wlan设备。这不是硬件问题，是内核版本问题。

三个组成部分的分工是这样的：驱动负责和硬件寄存器打交道、实现协议栈的收发逻辑；固件是跑在网卡芯片内部处理器上的二进制程序，负责射频控制和底层时序，很多功能驱动自己实现不了；内核模块是驱动编译出来的.ko文件，负责被加载和卸载。

判断问题出在哪一环，可以按这个顺序查：

# 1. 确认硬件是否被识别到 lspci -knn | grep -i -A3 network # 2. 确认驱动是否绑定 lsmod | grep -i rtw89 # 3. 看内核有没有报固件加载失败 dmesg | grep -i -E "rtw89|firmware" # 4. 确认射频开关状态 rfkill list all # 5. 确认网络接口是否存在 ip link show

如果lspci能看到设备但lsmod里没有驱动，说明驱动没加载，可能是内核版本不支持或者模块没编译；如果驱动加载了但dmesg里出现firmware load failed，说明固件文件缺失，需要把对应的bin文件放到/lib/firmware下；如果驱动和固件都正常但ip link里还是没有无线接口，那就要看rfkill是不是被硬开关或者软开关关掉了。

这里有个我自己踩过的坑：有些笔记本的无线网卡是通过一个物理开关或者Fn组合键控制的，如果开关处于关闭状态，驱动加载正常、固件也正常，但接口就是不出现，而且dmesg里可能只有一条很不起眼的提示。遇到"驱动全对但没WiFi"的情况，先按一下那个组合键。

3.2 Ubuntu下WiFi图标消失与unclaimed报错的排查链路

桌面环境里WiFi图标消失，底层通常对应几种情况：内核根本没识别到无线设备、驱动没绑定导致设备处于unclaimed状态、NetworkManager没有接管、或者无线接口被禁用。

"unclaimed"这个状态在lspci -knn的输出里会显示成Kernel driver in use:是空的，Kernel modules:列出了候选模块但没加载。这几乎可以确定是驱动层的问题，处理思路是按候选模块名去加载：

# 查看候选模块并尝试手动加载 sudo modprobe rtw89pci sudo modprobe rtw89_8852be # 加载失败时看具体报错 dmesg | tail -50

如果手动加载失败提示模块不存在，那就是内核里没有这个驱动，要么升级内核，要么自己编译驱动。升级内核时要注意，Ubuntu的HWE内核（Hardware Enablement）就是为这类新硬件准备的，装linux-generic-hwe-22.04这个包可以把内核升到较新版本，很多时候问题直接消失。

如果驱动加载成功但NetworkManager不管，可以检查服务的状态：

systemctl status NetworkManager nmcli device status sudo systemctl restart NetworkManager

还有一种情况是无线接口存在、驱动正常，但是界面上的开关是灰的，这通常是NetworkManager的无线开关被设成了关闭，可以用nmcli radio wifi on打开。我遇到过一次是路由器端的SSID用了特殊字符，导致NetworkManager扫描到了但连接配置写不进去，换个SSID就好了，这种问题查一天都查不到，只能靠排除法。

3.3 TX校准、功率控制与出厂参数到底是什么

做硬件或者做认证的时候，经常会看到"TX校准""功率校准"这类说法。简单说，这是芯片厂商在出厂或者生产阶段，为了补偿每颗芯片的射频特性差异而做的一系列测量和参数写入动作。

为什么需要校准？因为半导体工艺存在离散性，同一批芯片里，不同个体的功率放大器增益、滤波器特性、本振相位都会有差异。如果不做校准，有的芯片发射功率偏高，可能超出法规限制；有的偏低，覆盖范围就不够。所以芯片出厂时会通过自带测试模式（也就是常说的FTM，Factory Test Mode），逐颗测量不同信道、不同速率下的实际输出功率，把补偿值写进芯片的OTP或者外挂的EEPROM里。设备启动时驱动读取这些值，运行时按温度、信道、速率查表调整发射功率。

常见的校准项目包括：输出功率校准、IQ不平衡校准、载波频率偏移校准、以及高功率场景下的数字预失真校准。这些工作在正常产品开发里轮不到应用层开发者做，模块厂或者方案商会提供完整参数。但有一件事和应用层有关：法规域（regulatory domain）配置。如果设备的地区码设错，驱动会按错误的功率上限和信道列表工作，表现为某些信道不能用、或者发射功率被限制，看起来像是"信号特别差"。

3.4 2.4G与5G的取舍不是"越快越好"

选频段这件事，很多人只知道5G快，就无脑选5G，结果穿一堵墙就掉到没法用。

2.4GHz的优点是波长长、绕射和穿透能力强，缺点是频段拥挤，而且只有三个互不重叠的信道，在密集环境里干扰严重。5GHz的优点是信道多、干扰少、带宽大，能跑80MHz甚至160MHz，缺点是波长短、穿透损耗大，遇到承重墙衰减明显。

带宽的选择也有讲究。20MHz带宽抗干扰最好，40MHz在拥挤环境下反而可能因为占用更宽频谱而丢包更多。实测里我遇到过把信道带宽从40MHz强制改成20MHz后，实际吞吐反而提升的情况，原因就是干扰源变少了。

4. 模块级实操：蓝牙模块与WiFi模块怎么选、怎么调

讲完原理，说点具体的。这一节里的内容都是围绕几类我实际用过的模块展开的，包括HC-05/HC-06这类串口透传模块、ESP32这类带WiFi和蓝牙的SoC，以及移动端做BLE时踩过的那些坑。

4.1 HC-05/HC-06 透传模块的AT指令与无响应排查

HC-05和HC-06是最经典的串口透传模块，前者可以做主机也可以做从机，后者只能做从机。它们用的是经典蓝牙的串口透传，不是BLE，这一点选型时千万别搞混。

进入AT模式的方式：HC-05通常需要在断电状态下按住模块上的按键再上电，或者把KEY引脚拉高再上电，此时指示灯变成慢闪，表示进入AT模式，通信波特率是38400。HC-06没有按键，只能在未连接状态下直接发AT命令，波特率跟随工作波特率。

常用指令如下：

AT 查询通信状态，正常返回OK AT+NAME? 查询当前设备名 AT+NAME=MYBT 把设备名改成MYBT AT+ROLE? 查询主从角色，0从机，1主机 AT+ROLE=1 设置为主机 AT+UART? 查询串口参数 AT+UART=9600,0,0 设置波特率为9600，1位停止位，无校验 AT+PSWD? 查询配对码 AT+PSWD=1234 修改配对码 AT+RESET 重启模块

AT无响应是最高频的问题，按下面这个顺序排查基本都能定位：

第一，波特率不对。AT模式下的串口参数是固定的，不跟随工作参数，很多人拿着115200去发AT，当然没反应。

第二，命令结尾不对。AT指令必须以回车换行结尾，也就是\r\n，很多串口助手默认只发\r或者什么都不发，导致模块收不到完整命令。

第三，模块已经处于连接状态。HC系列在连接建立后会自动切到透传模式，不再接受AT指令。必须先断开连接，或者拉高KEY引脚再上电。

第四，供电不足。这类模块在配对和发射瞬间的电流可能超过40mA，如果用USB转TTL的3.3V引脚直接供电，电压会被拉低导致重启或者工作异常。建议单独给模块供电，或者用带独立稳压的底板。

第五，TX和RX接反。这个错误听起来很低级，但我见过太多次，而且表现和波特率错误一模一样。

有一个细节值得单独说：HC-05做主机的场景里，它只能连接从机模块，不能主动连接手机。因为手机做从机时用的服务和UUID和模块协议不匹配。想做手机和模块之间的通信，模块必须当从机。

4.2 ESP32同时跑蓝牙和WiFi：能跑，但要算账

ESP32因为同时带WiFi和蓝牙，且价格便宜，成了很多项目的首选。它确实支持两个功能同时工作，但有几个账要提前算清楚。

第一笔账是内存。WiFi协议栈加上TCP/IP协议栈大约占用50KB左右的RAM，BLE协议栈再占50到70KB，再加上应用程序、缓冲区、堆管理开销，如果芯片是标准的520KB SRAM版本，剩余空间会比较紧。项目里如果还要跑HTTP服务器、mDNS、OTA，很容易出现堆分配失败，表现为随机重启或者连接异常。做这类项目时，我习惯在启动后打印一次空闲堆的大小，运行一段时间后再打印一次，看有没有泄漏。

第二笔账是吞吐。前面提过，WiFi和BLE共享射频，同时跑的时候WiFi实测吞吐会明显下降。如果应用对WiFi速率要求高，就把BLE的占空比压下去，具体做法是拉长连接间隔、增大从机延迟。反过来如果BLE是核心功能，WiFi只做偶尔上报，那就让WiFi在空闲时才发包。

第三笔账是启动顺序和任务优先级。ESP-IDF里WiFi和蓝牙各自跑在不同的任务上，如果优先级设置不合理的组合，可能出现蓝牙任务长时间拿不到时间片，表现为连接超时。默认配置一般够用，如果自己调整过任务优先级，记得回来检查这一块。

配网这件事上有个常见需求：用BLE把WiFi的账号密码传给设备。这个方案本身很成熟，重点是要处理好几件事：传输的密码要做长度校验和格式校验，收到后立刻断开BLE再启动WiFi，避免两个射频模块同时初始化抢占资源导致启动失败。我自己做的设备里，这个顺序反过一次，现象是WiFi一直处在连接中状态，日志里能看到射频初始化失败。

4.3 蓝牙测距到底能做到什么精度

这几年蓝牙测距被提得很多，但很多人对它的精度预期是不现实的。需要区分几种技术路线。

基于RSSI的测距是最容易实现的，任何BLE设备都能做，原理是根据接收信号强度反推距离。问题是RSSI受环境影响极大：人体遮挡、天线朝向、多径反射，都会让同一个距离下的RSSI值波动十几dB。实际做下来，不经过大量滤波和现场标定，误差在1到3米是常态，环境复杂时更大。想用得靠谱一点，至少要采集一段时间的RSSI做滑动平均或者卡尔曼滤波，还要针对每种设备做参考功率标定，因为不同厂家的发射功率和天线增益差异很大。

基于角度的方案是蓝牙5.1引入的到达角/离开角定位，通过在接收端用天线阵列测量相位差来推算方向。它的优势是能给出角度而不只是距离，配合多个基站可以做二维定位，精度比纯RSSI好，但对天线阵列的设计和校准要求高，成本也上去了。

更新的路线是信道探测（Channel Sounding），蓝牙核心规范在6.0版本里引入了这套机制。它通过在不同频率上做双向的相位测量来估算距离，目标是做到亚米级甚至更好的精度。这个方向目前还在逐步落地阶段，选方案的时候要确认芯片和协议栈是否真的支持，不要只看宣传页。

做防丢器或者接近唤醒这类功能，RSSI足够了，重点是调阈值和加迟滞，避免在临界距离反复触发。如果要做室内定位，就要考虑多基站布点和角度方案了。

4.4 移动端BLE开发：Android、iOS、uni-app、Flutter的差异

移动端的坑主要集中在权限模型和设备标识这两件事上。

Android方面，12及以上版本把蓝牙权限拆成了扫描、连接、广播三组，扫描还需要位置权限配合，因为蓝牙扫描可以被用来推断位置。开发时要在清单文件里声明并在运行时申请，漏掉一个就表现为扫描无结果，而且不会有明显报错。另外Android返回的设备地址是真实的MAC地址，可以直接用来区分设备。

iOS方面完全不同。苹果不暴露MAC地址，deviceId实际是系统生成的UUID，同一台外设在不同手机上看到的这个值不一样，同一台手机卸载重装应用后也可能变化。所以想用"设备ID"来标识一台具体硬件，在iOS上必须靠自定义的广播数据或者特征值里的序列号，不能靠系统给的标识符。

跨平台框架方面，uni-app和Flutter都封装了原生蓝牙接口，但封装层会带来两个问题：一是错误码被包装过，排查时看不到原生层的具体返回；二是生命周期管理有差异，比如应用切到后台后扫描会被系统暂停，需要额外配置后台模式。

有一个共性问题值得单独提：连接建立后马上断开。这通常不是连接本身的问题，而是应用在连接成功后立刻发起了服务发现，而某些设备在这个阶段响应慢，导致超时。稳妥的做法是在连接回调之后延迟一小段时间再做服务发现，或者直接依赖系统的服务发现完成回调。

5. 高频问题速查表：现象、根因与处理动作

前面按原理和模块讲了这么多，最后把常见问题整理成表，方便直接对照。这些条目基本都是我在实际项目和社区里反复见到的。

5.1 蓝牙侧问题清单

Windows下蓝牙外设显示黄色感叹号或者问号，是很多人遇到的经典问题。多数情况下是系统没有识别到设备的GATT服务结构，原因可能是外设的配对流程不完整，也可能是某些定制服务没有按规范声明。处理办法是先删除配对记录重新配对，还不行就装厂商的驱动或者专用工具。

5.2 WiFi侧问题清单

省电模式这一条特别容易被忽略。Linux下有些无线网卡默认开启了省电策略，在流量空闲时会降低射频活动，表现为每隔一段时间掉一次线。关掉的方式是给驱动模块加参数，或者在NetworkManager的连接配置里把省电选项设为禁用。

5.3 桌面系统的几个典型场景

在Linux桌面上折腾无线网卡，还有几个高频场景值得单独记一下。一是内核升级之后无线网卡失效，原因通常是新内核里驱动模块名变了，旧的模块加载配置失效，这时候要重新确认模块名。二是系统更新后WiFi图标消失，多半是固件包被卸载或者NetworkManager服务异常，重启服务基本能恢复。三是同一块网卡在不同发行版上表现不一样，这是因为各发行版打包的固件版本和内核版本不同，遇到问题时要先核对这两项版本号。

我自己现在的排查习惯是固定一个顺序：先看设备是否识别，再看驱动是否绑定，再看固件是否加载，最后看上层服务是否接管。按这个顺序走下来，九成以上的WiFi问题都能定位到具体环节，比漫无目的地重装系统快得多。

最后分享一个在同时用蓝牙和WiFi的设备上试出来的小经验：如果产品允许，把WiFi优先固定在1、6、11中的某一个信道，并且把这个信息同步给蓝牙侧的广播信道选择逻辑，让BLE避开对应的频率。这个调整听起来很土，但在小批量设备上实测的丢包率改善相当明显，而且不需要改动任何射频硬件。