我做嵌入式开发和无线这块已经有些年头了，蓝牙和 WiFi 这对“老搭档”几乎每个项目都要碰一遍。不管是拿 ESP32 做智能家居网关，还是用 HC05 给单片机加个无线串口，又或者是在 Ubuntu 上折腾 Realtek RTL8852BE 那块 WiFi6 网卡的驱动，踩过的坑能写满一个笔记本。很多人刚入门时会把这两个技术混着理解，觉得都是“无线通信”，用哪个都行。实际上一旦深入到协议栈、组网方式、功耗模型和调试手段，两者的差别大到几乎是两个世界。这篇总结不是教科书那种按部就班的介绍，而是把我这些年做蓝牙、WiFi 项目时真正用得上的东西梳理出来：底层原理怎么理解、模块怎么选、协议栈怎么分层、ESP32 上蓝牙和 WiFi 到底能不能一起跑、驱动装不上怎么排查、连接老失败从哪下手。内容偏实操，适合刚接触无线通信的嵌入式新手，也适合做 IoT 产品、需要选型和调试的老手快速回顾。看完你至少能清楚：什么场景用蓝牙、什么场景用 WiFi、两者的调试思路为什么完全不同，以及遇到一堆报错时该往哪个方向查。

1. 蓝牙和 WiFi 到底差在哪：先把底层逻辑理清楚

1.1 频段与调制方式：都在 2.4G，为什么互不干扰

蓝牙和 WiFi 最容易被误解的一点，就是它们都跑在 2.4GHz 这个 ISM 免授权频段上，于是很多人第一反应是“那它们岂不是天天打架”。实际上两者虽然共用频段，但设计目标从一开始就不一样，这也决定了它们调制方式和抗干扰策略的差异。

经典蓝牙和 BLE 都采用 GFSK 调制，BLE 在 5.0 之后还支持 2Mbps 的 GFSK 符号率。它用的是跳频扩频（FHSS），经典蓝牙每秒跳 1600 次，BLE 的广播信道固定在 37、38、39 三个信道上，连接建立后则在 37 个数据信道间跳。跳频的意义在于：即使某个信道被 WiFi 或其他 2.4G 设备占用了，蓝牙也能快速跳到干净的信道上继续通信，所以它对窄带干扰有很强的耐受性。

WiFi 走的是完全不同的路子。以 802.11n/ax 为例，它用 OFDM（正交频分复用）把 20MHz 甚至 40MHz、80MHz 的带宽切成大量正交子载波并行传输，追求的是高吞吐。2.4GHz 频段里 WiFi 通常只划出 1 到 13（部分地区到 14）信道，每条 20MHz，而蓝牙的 79 个 1MHz 信道正好铺在里面。这也是为什么蓝牙和 WiFi 共存时，往往表现为蓝牙音频“卡顿”、WiFi 速率“掉档”，本质是两者在有限的频谱里互相让路。

理解这张表的意义在于选型。需要长时间电池供电、传少量数据（传感器、手环、遥控器），蓝牙尤其是 BLE 是首选；需要大带宽、连互联网、传视频，那只有 WiFi 能干。别指望用 BLE 传图片，也别想着用 WiFi 模块做纽扣电池续航一年的东西。

1.2 拓扑结构：一个是一主多从的小圈子，一个是中心化的星型网

拓扑结构的差异，是蓝牙和 WiFi 在系统设计层面最本质的分水岭，也是很多新手设计组网时最容易想当然的地方。

蓝牙的经典拓扑叫微微网（piconet）：一个主设备最多带 7 个活跃从设备，从设备之间不能直接通信，必须经过主设备转发。BLE 则更灵活一点，它基于广播和连接两种状态，一个中心设备可以连接多个外围设备，理论上数量可以更多，但实际受限于连接间隔和调度开销，几十个已经比较吃力。BLE Mesh 出现后才真正支持多对多的大规模组网，但它和点对点 BLE 是两套东西，别混用。

WiFi 的典型结构是 BSS（基本服务集），一个 AP 带若干 STA，也就是我们说的“连路由器”。多个 BSS 通过 ESS 组成一个大网络，靠 SSID 关联，支持漫游。WiFi 也支持 Ad-hoc（IBSS）和 Mesh（802.11s），但消费级产品里最常见、最稳的还是“AP-STA”这种中心化星型结构。

这个差异带来的直接影响是：蓝牙适合点对点、小范围的设备互联，比如手机连耳机、手机连手环、单片机连手机；WiFi 适合需要接入 IP 网络、多设备共享带宽的场景，比如摄像头、智能音箱、整屋的传感器网关。如果你的项目是“10 个传感器节点上报数据到网关”，用 BLE 会很别扭，用 WiFi 又太费电，这时候通常会考虑 BLE Mesh 或者专门的低功耗组网协议。

2. 协议栈拆解：蓝牙和 WiFi 各自的“楼层结构”

2.1 蓝牙协议栈：Controller 和 Host 到底怎么分工

很多人调蓝牙时被一堆名词搞晕：HCI、L2CAP、ATT、GATT、RFCOMM、SDP……其实只要抓住“Controller 管硬件、Host 管协议”这条主线，整个栈就清晰了。

最底层是物理层（PHY）和链路层（LL），负责射频收发、跳频、连接调度，这部分是硬件和固件实现的，也就是 Controller。Controller 之上是 HCI（主机控制器接口），它是 Host 和 Controller 之间的“分界线”，可以走 UART、USB 或 SPI。你用 HC05 时通过串口发 AT 指令，本质上就是在和 Controller 打交道。

Host 侧往上依次是 L2CAP（逻辑链路控制与适配协议），负责多路复用和分片重组；SMP（安全管理协议）负责配对和加密；ATT（属性协议）和 GATT（通用属性配置文件）则是 BLE 数据交互的核心。GATT 用“服务（Service）-特征（Characteristic）-描述符（Descriptor）”的树形结构组织数据，你读一个手环的心率，读的就是某个心率服务下的特征值。

经典蓝牙走的是另一套：RFCOMM 模拟串口（SPP 透传就靠它）、SDP 负责服务发现、AVDTP/AVCTP 支撑 A2DP 音频和 AVRCP 控制。所以经典蓝牙做音频、做串口透传很成熟，但协议重、功耗高；BLE 协议轻、功耗低，但带宽小、不适合音频流（LE Audio 是后来才补上的）。

BLE 建立连接的典型时序是这样的：外围设备先发广播包（Advertising），中心设备扫描到后发起连接请求（CONNECT_IND），连接建立后双方协商连接参数（连接间隔、从机延迟、超时），然后中心设备发起服务发现，最后才开始读写特征值。调 BLE 时如果连接上了却读不到数据，八成是服务发现没做完或者 UUID 对不上，而不是射频问题。

2.2 WiFi 协议栈与 802.11 家族：从管理帧到四次握手

WiFi 的协议栈用 OSI 模型来套会更顺。最底下是 PHY 层，对应 802.11b/g/n/ax 这些物理层标准；往上是 MAC 层，负责信道接入（CSMA/CA）、帧的封装和重传；再往上就是常见的 IP、TCP/UDP、应用层。和蓝牙相比，WiFi 在链路层之上就直接对接标准 TCP/IP 协议栈了，这也是它“天生能上网”的原因。

WiFi 连接的过程其实分两步：先“关联”，再“认证加密”。扫描阶段设备发 Probe Request 或监听 AP 的 Beacon 帧，拿到 SSID 和加密能力；关联阶段发 Authentication 和 Association 帧，和 AP 建立链路；最后是安全握手，WPA2 用四次握手（4-Way Handshake）派生会话密钥，WPA3 则用 SAE（对等实体同时认证）来抵抗离线字典攻击。

这里插一句关于无线安全的理解。很多人搜索 WiFi 密码相关的工具和字典，是因为对这套握手过程好奇。从技术角度看，WPA2 的四次握手确实是安全研究的经典对象，但它的正确用法是帮我们理解“为什么弱密码不安全”。站在防御角度，你能做的事很明确：把路由器加密方式设成 WPA2-AES 或 WPA3，密码长度拉到 12 位以上、混合大小写数字符号，关闭 WPS 的 PIN 方式，定期更新固件。至于在别人的网络上做任何测试，那是法律红线，本文不涉及也不建议。

搞清楚这两套栈的对应关系，调试时就不会串线。蓝牙连不上先查广播和配对，WiFi 连不上先查关联和密钥，这是两条完全不同的排查路径。

3. 模块选型与开发环境搭建：别一上来就选错芯片

3.1 常见蓝牙模块：HC05、HC06、ESP32、杰理怎么选

新手接触蓝牙模块，十有八九是从 HC05 或 HC06 开始的。这两个模块便宜、资料多，但定位很明确：它们都是经典蓝牙 SPP 透传模块，本质是把蓝牙当成“无线串口”用。HC05 可以做主机也可以做从机，通过 AT 指令切换角色；HC06 只能做从机，配置更简单，价格也更低。它们的典型接线是 VCC、GND、TXD、RXD 四根线，注意 TXD 要接单片机的 RX，RXD 接单片机的 TX，交叉连接，很多人第一次接反了导致完全没反应。

如果你要做 BLE 或者双模，HC05/HC06 就不够用了。这时候 ESP32 是性价比之王：它内置蓝牙经典 + BLE 双模，同时还有 WiFi，一颗芯片把无线全包了。Nordic 的 nRF52 系列在低功耗 BLE 上更专业，适合做手环、传感器节点。杰理（JL）和 BES 的芯片在蓝牙音频领域（TWS 耳机、音箱）出货量巨大，但它们的开发环境和通用 MCU 差别很大，通常需要原厂 SDK 和专用工具，不适合拿来学通用蓝牙开发。

选型的核心逻辑就三条：只做串口透传，HC05/HC06 够了；要 BLE、要低功耗、要自己写协议，ESP32 或 nRF52；要做音频产品，才去碰杰理、BES 这类专用方案。别为了省几块钱选错方向，后面 SDK 的学习成本远超芯片差价。

3.2 WiFi 模块与驱动：从 8852be 到 Ubuntu 无 WiFi 图标

WiFi 模块分两大类：一类是“模块 + MCU”的透传方案，比如 ESP8266、ESP32 自带的 WiFi，用 AT 指令或者直接编程；另一类是给 PC/Linux 主机用的网卡，比如 Realtek RTL8852BE 这种 WiFi6 + 蓝牙5.2 的组合卡。

在 Linux 上装 WiFi 网卡驱动是老生常谈的坑。Ubuntu 下装完系统发现右上角没有 WiFi 图标，一查lspci能看到网卡，但dmesg报 “unclaimed”，多半是驱动没加载或者固件没装。排查顺序我一般是这样的：

# 1. 确认网卡是否被识别 lspci -nnk | grep -iA3 network # 2. 看驱动有没有绑定，未绑定时会显示 "Kernel driver in use" 为空 lspci -k # 3. 查内核日志里的固件加载失败信息 dmesg | grep -i firmware # 4. 检查无线是否被软/硬开关禁用 rfkill list all

如果看到固件加载失败，通常是/lib/firmware下缺对应的 bin 文件，需要从发行版仓库或厂商驱动包里补齐。RTL8852BE 这类较新的卡，老内核可能根本没带驱动，升级内核或者装 backport 驱动是常见解法。另外注意，很多组合卡的 WiFi 和蓝牙是两个独立驱动模块，WiFi 正常不代表蓝牙就能用，蓝牙部分往往还要单独装固件。

提示：遇到 “unclaimed” 不要急着重装系统，先确认三件事——内核版本是否支持该芯片、固件是否齐全、rfkill 是否把无线锁了。这三步能解决大部分“无 WiFi 图标”的问题。

4. 实操：从零跑通蓝牙与 WiFi 共存

4.1 ESP32 上蓝牙和 WiFi 能不能一起用

这个问题被问得极多，答案是：能，但有代价。经典 ESP32（不是 S3）用的是共享射频前端，2.4GHz 的收发只有一套，蓝牙和 WiFi 要么分时复用，要么靠软件协调。官方提供了共存（coexistence）机制，通过在协议栈层面协商，让蓝牙和 WiFi 轮流占用射频。实测下来，WiFi 和 BLE 同时工作时，WiFi 吞吐会明显下降，蓝牙音频还会出现断续，因为射频资源被抢了。

需要特别注意的是 ESP32-S3 这一代，它只支持 BLE，不支持经典蓝牙，很多人在 S3 上想跑 SPP 串口透传结果发现跑不了，就是踩了这个坑。如果你的项目必须同时要 WiFi 和经典蓝牙（比如做蓝牙音箱 + 联网控制），那得选经典 ESP32 或者外挂一颗蓝牙芯片。

一个典型的共存场景是这样：ESP32 连上 WiFi 上报数据，同时开一个 BLE 服务给手机配置参数。关键做法是把 WiFi 和 BLE 的任务优先级、信道规划调好。工程上我通常这样处理——WiFi 连接集中在启动阶段和低频上报时，BLE 保持常驻但连接间隔设大一点（比如 100ms 以上），把两者对射频的争抢降到最低。

// ESP32 同时初始化 WiFi(STA) 和 BLE 的骨架示意 #include "esp_wifi.h" #include "esp_bt.h" #include "esp_gatts_api.h" void app_main(void) { // 1. 初始化 NVS（WiFi 和 BLE 都要用） esp_err_t ret = nvs_flash_init(); if (ret == ESP_ERR_NVS_NO_FREE_PAGES) { nvs_flash_erase(); nvs_flash_init(); } // 2. 先起 WiFi STA esp_netif_init(); esp_event_loop_create_default(); wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT(); esp_wifi_init(&cfg); esp_wifi_set_mode(WIFI_MODE_STA); esp_wifi_start(); // 3. 再起 BLE 控制器和 Host esp_bt_controller_config_t bt_cfg = BT_CONTROLLER_INIT_CONFIG_DEFAULT(); esp_bt_controller_init(&bt_cfg); esp_bt_controller_enable(ESP_BT_MODE_BLE); esp_bluedroid_init(); esp_bluedroid_enable(); // 4. 注册 GATT 事件回调，开始广播 // ...（略） }

这段代码的重点不在语法，而在顺序：先初始化 WiFi 再起蓝牙，能减少启动阶段的射频冲突。很多人反过来写，结果蓝牙广播都被 WiFi 扫描打断了。

4.2 蓝牙透传与调试工具：AT 指令和调试助手怎么配合

用 HC05 做透传，第一步是进入 AT 模式。通常是把模块上电前按住按键，或者把某个引脚拉高，然后串口波特率设成 38400（AT 模式下的默认值，数据模式是 9600 或 115200，看模块版本）。进 AT 模式后能收到 “OK”，说明通信正常；如果发 AT 完全没响应，先查波特率、查 TX/RX 有没有交叉、查供电是否够（HC05 对电压和电流比较敏感，供电不足会表现为连不上或频繁掉线）。

常用 AT 指令其实就那么几条：查询和设置名称AT+NAME、查询和设置波特率AT+UART、查询和设置配对码AT+PSWD、切换主从角色AT+ROLE。配置完记得重启模块让参数生效，很多人配完不重启，以为没生效，其实是参数还没加载。

手机端的调试工具，安卓可以用“蓝牙调试助手”这类应用，直接开串口透传收发数据；调 BLE 的话用 nRF Connect 更专业，能看到所有的服务和特征值，还能手动读写。iOS 上因为 BLE 权限和后台限制比较多，Flutter 用 BLE 插件时经常会遇到“能扫描到但连不上”或者“后台被系统挂起”的问题，这类多半是 iOS 对后台蓝牙的限制导致，需要在工程配置里勾选后台模式，并且连接参数要符合苹果的规范，间隔不能太小。

实操心得：调蓝牙透传时，先用调试助手和模块单独通信，确认模块本身没问题，再接单片机。这样能把“模块问题”和“代码问题”分开，排查效率高很多。

5. 常见问题与排查速查表：连接不上先看这里

5.1 连接类问题：从 HC05 到 Android BLE

蓝牙连接失败是最常见的一类问题，但原因五花八门。我整理了一张速查表，基本覆盖了大家搜得最多的几个场景。

拿 HC05 连不上来说，最常见的是它已经和上一个手机绑定了。HC05 是单连接从机，同一个时刻只能被一个设备连，如果之前的手机没断开，新设备是连不上的。解决办法是让旧设备断开或者把模块重新上电。

Android BLE 这块，很多人卡在“连接成功但读数据失败”。这通常是因为 BLE 的连接成功只是链路建立，真正的数据交互要走 GATT。正确的顺序是：连接成功后先调discoverServices()，拿到服务列表后再找目标特征值，最后才读写。跳过服务发现直接读，必然失败。另外 Android 在 BLE 权限上是分版本变化的，Android 12 之后蓝牙扫描需要独立的 BLUETOOTH_SCAN 权限，权限不全也会导致扫不到设备。

5.2 驱动与系统类问题：Linux 和 Windows 的坑

系统层面的问题往往更折磨人，因为它们不报业务错误，只有一句冷冰冰的“unclaimed”或者设备管理器里的黄色问号。

Ubuntu 22.04 装 Realtek RTL8852BE 这类网卡，如果内核版本不够新，驱动缺失是常态。除了前面说的升级内核和补固件，还有一个容易忽略的点：Secure Boot。有些发行版在开启 Secure Boot 时会拒绝加载未签名的第三方驱动，导致驱动装了却不生效。这时候要么给驱动签名，要么在 BIOS 里关掉 Secure Boot。

Windows 上 360 随身 WiFi 在 Win10/Win11 用不了，多半是驱动签名或系统版本兼容问题，老设备的驱动没跟上系统更新。解决办法是去官网找最新驱动，或者换用系统自带的移动热点功能，现在 Windows 自带的“移动热点”其实已经能替代大部分随身 WiFi 的功能了。

注意：处理驱动问题前，先记录下内核版本、网卡型号、驱动模块名这三个信息，再去搜，命中率会高很多，别上来就一通乱装。

6. 无线安全与合规使用：把技术用在正道上

6.1 保护自己的无线网络：比研究怎么进别人的网更重要

既然聊到 WiFi，绕不开安全。与其琢磨怎么连上别人的网络，不如把自己家的网络加固好，这才是真正有用、也不会有任何麻烦的技能。

第一，加密方式选 WPA2-AES 或 WPA3，别用已经淘汰的 WEP 和 WPA-TKIP。第二，密码至少 12 位，大小写、数字、符号混合，别用生日、手机号这种一看就能猜到的组合。第三，关掉 WPS 的 PIN 方式，WPS 的 PIN 存在被暴力尝试的风险，很多老路由器默认开着。第四，定期更新路由器固件，厂商修补的漏洞大多和固件有关。第五，如果路由器支持，把访客网络单独开出来给智能设备用，主网络留给手机电脑，隔离风险。

蓝牙这边也有安全细节。BLE 配对分 Just Works、Passkey、OOB 几种方式，Just Works 没有中间人防护，适合不涉及敏感数据的设备；涉及支付、门锁这类，一定要用带认证的配对方式。做产品时别图省事全用 Just Works，否则数据容易被旁路监听。

6.2 调试的边界：什么能做，什么绝对不能碰

学无线技术，动手实践非常重要，但前提是在自己的设备、自己的实验环境里做。想研究 WiFi 的认证过程，可以拿自己的路由器开一个隔离的测试网络，用抓包工具分析四次握手，观察加密前后的差异。这类学习是合法且非常有价值的，能帮你真正理解协议。

但任何针对他人网络的探测、接入、干扰行为，都是明确越界的。技术本身没有对错，用在哪里才是关键。同理，抓包分析蓝牙通信也应在自己的设备上进行，很多开发板都支持把 HCI 日志导出来分析，这比盲目地“破解”更有意义，也更能锻炼真正的调试能力。

7. 调试心得与经验收尾

做无线这块，我觉得最值钱的能力不是背协议，而是“分层定位”。蓝牙出问题，先在射频层确认广播有没有发出去，再到链路层确认连接参数，最后到 GATT 层确认服务对不对；WiFi 出问题，先确认驱动和 RSSI，再确认关联和认证，最后才查 IP 和 DNS。每一层都用对应的工具验证，不要一上来就改代码。

另外一个体会是，工具一定要用好。调 BLE 就装 nRF Connect，看服务和特征值一目了然；调 WiFi 就学会看iwconfig、dmesg、rfkill这几个命令；调 ESP32 记得把日志级别打开，协议栈的报错信息其实非常详细，只是很多人不看。最后再分享一个小习惯：每换一个新的模块或芯片，先跑一个最小的点灯或者透传例程，确认链路通了，再往上加业务逻辑。这样即使后面出问题，你也能确定到底是基础链路的问题，还是自己代码的问题，排查范围能缩小一大半。