IoT设备无线选型：Wi-Fi 6、蓝牙LE与Combo的取舍之道

先说一个很多人在选型会议上容易踩的坑：谈起“Wi-Fi 6、蓝牙 LE、Combo 三选一”，第一反应永远是从规格书里翻数据速率、翻功耗、翻引脚定义，结果翻完更纠结。做 IoT 设备无线方案选型，本质上不是比参数大小，而是拿功耗、带宽、时延、成本、供应链、认证周期这一堆互相打架的指标去做产品定义的取舍。选错一步，后面打样、过认证、量产爬坡全是连锁反应。

这篇内容不是给某个芯片厂商站台，也不是堆规格书翻译，而是把我在智能家居、传感器、可穿戴这几个方向做无线选型时真正会算的账、真正会踩的坑，按一套能直接拿来用的思考框架重新过一遍。如果你正在评估一款产品该用 Wi-Fi 6、蓝牙 LE、还是直接上 Combo 模组，这篇文章应该能帮你少开三次无意义的评审会。

1. 三种方案到底在争什么：先看产品形态再谈技术指标

无线方案选型最忌讳的事情，是拿着技术规格反推产品场景。Wi-Fi 6、蓝牙 LE、Combo 这些词代表的不只是“速率快不快、功耗低不低”，而是三种截然不同的产品连接哲学。Wi-Fi 6 是“接入已有网络基础设施”的思路，蓝牙 LE 是“点对点直连、超低功耗”的思路，Combo 则是“我全都要”的工程妥协。

1.1 从产品定义出发，而不是从芯片选型出发

我见过太多项目组先定芯片，再回头编产品故事。结果做出来的东西要么功耗扛不住电池容量，要么配网体验差到用户直接退货。正确顺序应该反过来：先搞清楚这个产品往哪儿放、谁来操作、数据多久传一次、用户对时延能不能忍、生产线上怎么测试，再回头看 Wi-Fi 6、蓝牙 LE、Combo 哪个能接住这些需求。

举个例子，一个家用温湿度传感器，产品定义很明确：两节 AA 电池供电，5 分钟上报一次数据，用户用手机 App 查看，最好能远程 OTA 升级固件。这种情况下，数据量极小、上报频率极低、必须省电，蓝牙 LE 天然合适。但如果同一个产品要求 24 小时视频监控实时回传，那蓝牙 LE 直接出局，Wi-Fi 6 才是正经答案。

所以说三种方案的竞争表面上是技术之争，实际上是产品形态决定连接需求，连接需求再决定无线协议。做选型时先列出一张产品需求清单，比对比一百个 datasheet 都管用。

1.2 一张表看清三种方案的能力边界

把关键维度拉出来放在一起看，很多看起来复杂的选择会变得特别直白。这里整理了一张常用的对比表，基于当前主流 IoT 芯片和模组的实际表现，不是理论峰值。

这份表格解决的是“大方向”问题。举个例子，如果你看到表格里“Combo 模组成本最高”就立刻排除它，那很可能会错失它带来的配网体验和产测便利性。成本账不能只看 BOM，这个后面我会专门展开。

1.3 一个实用判断：单协议起步，还是直接 Combo

很多团队问我的第一个问题就是“能不能先用一个协议顶住，后面再换”。理论上可以，实际上换无线方案等于重新画板子、重新过认证、重新调天线，成本不比做一版新 PCBA 低。

我的经验是：如果产品后续一定会做 App 配网、一定会做远程 OTA、一定会采集数据上云，那这三个“一定会”加在一起，Combo 几乎是必然选择。蓝牙负责配网和本地控制，Wi-Fi 负责数据传输和 OTA，各干各擅长的事，系统整体的功耗和体验都是最优的。

反之，如果产品只跟自家网关通信、不需要手机直接参与、数据量也小，那单 BLE 够用。比如楼宇里的传感器网络，网关统一收集数据，BLE 的低功耗优势能得到最大发挥，完全没必要为 Wi-Fi 功能买单。

2. 核心细节解析：Wi-Fi 6、蓝牙 LE、Combo 的底牌各不相同

方向定完之后，就要沉到具体协议和芯片能力层面去看细节了。很多工程师知道 Wi-Fi 6 快、蓝牙 LE 省电，但说不清楚为什么快、为什么省电、Combo 为什么能“两者兼得”。这些底层机制才是选型时真正要理解的东西。

2.1 Wi-Fi 6 给 IoT 带来的不是“快”，而是“省”和“稳”

Wi-Fi 6 也就是 802.11ax，大家最熟悉的是它对手机速率和延迟的改善。但在 IoT 场景里，Wi-Fi 6 真正值钱的是另外三个能力：TWT（目标唤醒时间）、OFDMA、BSS Coloring。

TWT 是 Wi-Fi 6 面向电池驱动设备最重要的功能，它的思路特别朴素：AP 和设备提前约定一个“唤醒时间表”，设备平时深度睡眠，到点才醒来收数据。早期 Wi-Fi 设备为了维持连接，至少每隔一个 DTIM 周期就要醒来听一次 Beacon，几百毫秒醒一次，平均电流很难压下去。开了 TWT 之后，唤醒间隔可以拉到几秒甚至几十秒一次，待机功耗能压到接近蓝牙的级别，这对电池供电的 Wi-Fi 设备是质的改变。

OFDMA 解决的问题是高密度场景下的信道利用率。比如家庭里有二十台 IoT 设备同时连一个路由器，802.11ax 可以在一个 OFDM 帧里同时给多台设备传输数据，减少碰撞和等待。BSS Coloring 则是解决相邻路由器互相干扰的问题，打个比方，以前两家人在一个房间里同时喊话，双方都听不清；现在给声音染了不同颜色，同一时刻也能区分谁是谁家的内容。

不过要泼一盆冷水：Wi-Fi 6 的功耗优势必须搭配支持 TWT 的 AP 路由器才能发挥。如果你面对的是老旧路由器存量市场，或者工业现场根本没有可控 AP，那 TWT 可能长期处于“芯片支持但网络不支持”的尴尬状态。选型前一定要确认产品实际运行环境中的路由器更新情况，不能只看实验室数据。

2.2 蓝牙 LE 不只是一套协议，而是一整套低功耗方法论

先回应一个在开发社区里被反复搜索的问题：“蓝牙 le是什么意思”。蓝牙 LE 是 Bluetooth Low Energy 的缩写，中文叫低功耗蓝牙，从蓝牙 4.0 开始作为一套独立协议栈引入，和经典蓝牙 BR/EDR 是两条并行路线。它不是“蓝牙 4.0 的低功耗版本”，而是为了应对物联网低功耗连接从头设计的新协议。

BLE 的省电机制主要体现在几个层面。第一是发射功耗本身低，BLE 广播和连接的占空比极低，绝大部分时间处于 sleep 状态。第二是连接参数可以动态调整，设备可以通过修改 connection interval、slave latency、supervision timeout 三个参数，在“响应速度”和“省电”之间做平衡。比如一个温度传感器，连接间隔设到 100ms，从机延迟设到 4，相当于设备每 500ms 才需要真正收发一次，平均电流下降非常明显。

BLE 5 之后引入了更高速度的 2M PHY、更远距离的 Coded PHY、以及广播扩展能力。2M PHY 能把吞吐推到 1.4 Mbps 左右，Coded PHY 用冗余编码换距离，可以到几百米，但速率会降到 125kbps 左右。这个取舍很关键，不是所有场景都适合用 Coded PHY，很多人一看“距离几百米”就无脑开，结果数据速率根本不够传图片，反而误事。

BLE 还有一个对产品体验特别重要的点：手机原生支持。安卓和 iOS 系统级支持 BLE，App 可以直接扫描、连接、收发数据，不需要额外的硬件网关。这让 BLE 在“手机直连”场景里几乎没有对手，也是智能门锁、蓝牙标签、健康手环全部采用它的根本原因。

2.3 Combo 方案的底气：1 + 1 不只是等于 2

Combo 模组本质上是在一颗 SoC 或一个模组里同时集成 Wi-Fi 和蓝牙协议栈。我最早接触 Combo 是在智能音箱方案里，当时觉得纯粹是“因为要做配网所以顺便焊一颗蓝牙”，后来才意识到 Combo 的价值远不止省一颗芯片那么简单。

第一层价值是共享射频前端和天线。一颗 Combo 模组可以用一根天线通过内部开关或双工器在不同时间片里跑 Wi-Fi 和蓝牙，PCBA 上天线净空区只需要留一处，这对体积敏感的产品太重要了。如果买独立 Wi-Fi 和独立 BLE 两颗芯片，就要两套匹配电路、两根天线，板子面积和调试工作量直接翻倍。

第二层价值是软件协议栈的耦合。Combo 芯片内部一般会有专门的共存机制（PTA，Packet Traffic Arbitration），在 Wi-Fi 收发和 BLE 收发冲突时做仲裁，避免互相干扰。这个在单独的两颗芯片方案里很难做，通常需要外接额外逻辑或忍受概率性的丢包。我在一个项目里踩过这个坑，Wi-Fi 和 BLE 分开走，通信一频繁 BLE 就狂重传，最后只能硬件上错开信道，体验非常痛苦。

第三层价值是配网和产测流程的简化。Combo 模组可以先通过 BLE 广播快速建立手机连接，App 把 Wi-Fi 账号密码通过 BLE 通道传给设备，然后设备切到 Wi-Fi 联网。用户感知是从“扫二维码再手动输密码”变成“App 直接弹窗搜索设备”，配网成功率显著提升。生产线上也可以靠扫描 BLE 广播包快速识别设备，不用每一台都连着路由器测试。

现在 Matter 标准流行起来以后，Combo 更是成为了很多 Matter 设备的默认选择。Matter 的配网流程要求先走 BLE，后续数据链路走 Wi-Fi 或 Thread。如果模组不带蓝牙，连 Matter 认证都过不了。所以在这个时间点评估无线方案，Combo 不只是一个可选项，而是一个面向未来的基础配置。

3. 选型时真正要算的几笔账：功耗、数据量、成本与供应链

方向明确之后，选型就进入“算账”阶段。这里的账不是纸上谈兵的指标对比，而是要把产品定义里最核心的约束条件逐条转成工程量。我的经验是重点算清三笔账：功耗账、数据账、成本与供应链账。

3.1 功耗账：用电池还是用电源，决定你是哪条难度曲线

功耗计算不能只看芯片手册里的 RX/TX 电流，那只是“工作瞬间”的值。真正决定续航的是平均电流，也就是把工作、睡眠、广播、连接、重传所有这些状态按时间占比做一个加权平均。

我习惯拿 500mAh 纽扣电池做例子来说清楚这件事。假设一个 BLE 温度和湿度传感器，sleep 电流 2µA，每 10 分钟醒来广播一次，每次广播持续 10ms，广播电流 20mA。平均电流大约是 2 + 20mA × 0.01s / 600s，算下来只有 2.33µA。500mAh 除以这个平均电流，理论上电池能撑二十多年，实际上最终会被电池自放电和超低温环境限制，无线链路的功耗几乎可以忽略。

同样一块 500mAh 电池，如果设备用传统 Wi-Fi 保持连接，路由器 DTIM 周期按 100ms 算，芯片每 100ms 就要醒来听 Beacon 一次。就算单次唤醒电流只有 5mA 的平均水平，500mAh / 5mA = 100 小时，也就是四天出头。如果用 Wi-Fi 6 的 TWT，把唤醒周期拉到 10 秒，平均电流可以压到 0.2mA 附近，续航能拉到一百天左右。但还远不能跟 BLE 比，所以真正用电池的 Wi-Fi 产品通常会用大容量锂电池或者可充电设计，而不是一颗纽扣电池打天下。

选型时请务必把这个账算到“平均电流 × 工作时间 = 电池容量”这一步。我见过最典型的问题是一个团队拿着“Tx 200mA”的峰值电流去评估续航，算出来电池只能用一天，急得团团转，实际上设备每天只工作五分钟，绝大部分时间都在 sleep，实际平均电流只有几十微安，续航根本没有问题。

3.2 数据账：你要传的数据到底是什么

数据量是另一个经常被高估或者低估的变量。我常用“数据占空比”来定义场景：控制指令几十个字节，遥测数据几百个字节，音频流几十到几百 kbps，视频流几百 kbps 到几十 Mbps。占空比不同，方案选择完全不同。

如果产品只是周期上报传感器数值，比如温湿度、空气质量、门锁状态，单次几十个字节，一天传几十次，那么 BLE 完全够用。就算 BLE 5 的实际有效吞吐被协议开销压制到几百 kbps，传这些数据也是绰绰有余。这时候硬上 Wi-Fi 反而是给自己找麻烦，功耗、成本、软件复杂度全都上去了。

如果产品要传音频分享、实时摄像头画面、或者频繁升级几十 MB 的固件，那只能用 Wi-Fi。蓝牙的吞吐上限放在那里，传一张照片勉强可以，传一段视频体验就是灾难。有很多产品折衷处理：行动作和控制走 BLE，要传大文件或视频时再切换到 Wi-Fi，这正好是 Combo 模组的典型工作方式。

3.3 成本与供应链账：BOM 只是冰山上的一角

很多产品经理看成本只看模组单价，Wi-Fi 6 模组贵，BLE 模组便宜，Combo 最贵。但整个项目成本远不止这些：天线、匹配电路、PCB 面积、结构开孔、认证费用、产测工装、软件维护人力，都在账本上。

认证是最容易忽略的大头。Wi-Fi 产品需要过 SRRC、FCC、CE 等无线认证，蓝牙产品还需要蓝牙 SIG 的声明和认证。如果买一颗通过了相关认证的 Combo 模组，二次开发产品可以直接引用模组的认证报告，省下一大笔认证费用和好几个星期的认证周期。独立的两颗芯片方案就要分开过认证，费用和时间接近翻倍。这个隐性成本算进去以后，Combo 反而可能是最省钱的方案。

供应链角度也要给自己留后手。Wi-Fi 6 和蓝牙 LE 芯片的供应商选择范围不一样，BLE 方案基本是几家头部厂商的产品，成熟稳定，备货周期短。Wi-Fi 6 IoT 芯片的选择相对少一些，部分产品还绑定特定平台。Combo 模组的供应商相对集中，好处是软硬件一体、风险可控，坏处是被绑定得更深。选型前最好确认一下目标模组有没有二供，以及二供的 pin to pin 兼容性，别在量产爬坡期被一颗料卡住整个项目。

4. 实操过程：从需求表到打样实测的几个关键环节

选型不是开完会定个料号就结束，真正的工作是从拿到评估板到首板回来测试的整个流程。这个阶段我积累了几个特别实用、但很少出现在官方文档里的方法。

4.1 先做一张能逼自己做决策的需求对照表

我每做一个选型评估，第一件事是拉一张表，把产品需求逐条列出来。这套方法看起来简单，但真的能逼着团队把所有模糊表述变成明确参数。比如“要省电”要写成“两节 AA 电池供电，目标续航 18 个月”，“要云端连接”要写成“设备需接入家庭路由器，数据上报间隔 5 分钟，单包大小不超过 200 字节”。

下面是之前做一个智能门锁时整理的需求表，可以用来参考：

填完这张表之后，结论已经非常明确：这颗智能门锁几乎必须是 Combo 方案，BLE 负责开门和控制，Wi-Fi 负责照片和 OTA。如果非要省钱去做单 BLE，那远程看照片这个核心卖点就没了，产品定义本身要改。

4.2 拿到评估板后的第一轮无线实测

评估板到手之后，别急着跑 demo 程序，先把四件事测完：RX 灵敏度、TX 功率、实际吞吐量、以及低功耗模式的 sleep current。这些数值会直接决定方案能不能落地。

RX 灵敏度和 TX 功率可以用综测仪或者通过板厂提供的软件工具来看。没有综测仪的话，粗略一点就用两个评估板对拉，看距离拉多远开始掉包。吞吐量用 iperf3 打流测 Wi-Fi，BLE 可以用手机或者另一块板子做连续大包传输测试。sleep current 用功耗分析仪或者万用表串在供电回路上测，重点看设备进入 sleep 之后的电流曲线是否干净。

这里有一个很关键的实操建议：测试环境一定要避开办公室电脑集中区。2.4GHz 频段的 WiFi、蓝牙、甚至 USB 3.0 接口都会产生干扰，在电脑密集的办公桌上测出来的数据根本没有参考价值。有条件就去屏蔽房加定向衰减器，没有条件就选办公楼里相对空旷的走廊或者会议室角落，保证测试环境的可比性。

4.3 天线设计：范围缩水的头号嫌疑人

模组再好，天线设计一塌糊涂，整个方案的性能就废了。我总结过一句话：无线性能一半在芯片，一半在天线周围的地和净空区。很多工程师拿到参考设计直接画板，天线区域旁边的走线、铺铜、结构件遮挡全都处理得很随意，结果实测距离直接减半。

板载天线和 IPEX 外接天线之间，我的偏好是先看产品结构。外壳是塑料且天线周围净空足够的，板载天线问题不大；金属外壳、或者天线周围有螺丝柱、电池、喇叭等金属物体的，直接上 IPEX 外接天线，省得后面反复调结构。天线匹配电路旁边预留 π 型匹配的位置，这个习惯能让你在认证测试前多几个调试手段。

调试天线时最有效的工具是矢量网络分析仪看 S11，其次就是老老实实做无线拉距测试。别只看 RSSI，还要看丢包率和重传率，这两个指标在临界距离处比 RSSI 敏感得多。

4.4 软件协议栈与上层应用架构

无线方案选定后，软件层面的工作量经常被低估。不同芯片的协议栈成熟度差异巨大，BLE 方面像 Nordic、TI 这些老牌厂商的 SDK 非常成熟，MCU 开发资源多。Wi-Fi 方面则要关注协议栈是不是实时操作系统环境、有没有提供完善的 TCP/IP 网络接口、配网机制是 SoftAP 还是 SmartConfig 还是 BLE 配网。

配网体验是智能硬件用户最容易感知的部分。普通的 Wi-Fi 设备第一次使用，要么让用户进 AP 模式输入 Wi-Fi 密码，要么用 SmartConfig 在 App 里选网，前者繁琐、后者在路由器隔离 AP 或者 5GHz/2.4GHz 混杂环境下经常失败。Combo 方案的 BLE 配网体验最好，App 直接搜索附近的 BLE 广播，点一下设备就完成配网。这种“手机通信录里直接拽联系人”的感受是完全不一样的。

顺带说一个开发过程中的小提醒：很多团队在 Windows IoT Enterprise 的调试主机上花时间装系统、装语言包，其实这不是重点，真正耽误时间的是评估板的 USB 驱动和串口驱动没装好，导致硬件日志永远打不开。先把烧录和日志链路打通，再谈无线调试，能省很多无效等待。

5. 常见问题与排查技巧实录

最后整理一些我在实际项目里反复遇到、并且有明确排查思路的问题。这些问题在芯片官方文档里很难直接搜到完整答案，但项目现场几乎每天都会碰到。

5.1 BLE 和 Wi-Fi 放在一起就打架，怎么压下去

这是 Combo 方案最常遇到的问题。2.4GHz 频段本来就窄，BLE 的 2.4G 和 Wi-Fi 的 2.4G 如果同时收发，就会在射频前端形成竞争。现代 Combo 芯片基本都有 PTA 硬件仲裁机制，但前提是你在软件侧正确配置了优先级策略。Wi-Fi 是骨干数据链路，BLE 是控制链路，默认配置有时会让 BLE 等太久，导致门锁按键反应迟钝、App 控制没响应。反之，如果 BLE 优先级太高，Wi-Fi 的吞吐又会掉得很难看。这个平衡没有通用参数，必须拿实际场景打流去调，我在项目中通常会把“用户可感知的关键操作”设为最高优先级，比如门锁解锁指令、App 配网指令。

5.2 功耗显示几百 µA，结果电池还是撑不住

功耗问题九成不在无线芯片本身，而在系统集成。我遇到过一个“低功耗智能门锁”，单独测模组 sleep 电流只有几微安，整机待机却跑到了 2mA。排查到最后发现是门磁传感器的上拉电阻直接接在电池正极上，从来没断过电。另一个典型案例是电源芯片的静态电流本身就接近 100µA，直接把无线芯片辛苦省下来的功耗全部吃掉了。所以功耗排查一定要做整机分解，逐个子模块量电流，而不是只看无线方案的指标。功耗分析仪、或者简单串一个 10Ω 采样电阻用示波器抓压降，都是可行的方案。

5.3 BLE 距离缩水，先检查天线净空区

BLE 标称距离在开放场地可以到几十米甚至上百米，到了实际产品里缩到十米以内的情况太常见了。第一个怀疑对象永远是天线周围有没有金属和走线。之前做一个追踪器，电池放在了天线正下方，拉距测试做一次郁闷一次。后来把电池挪走、在结构设计上强制留出净空区，距离立刻翻倍。第二个怀疑对象是连接参数，有些协议栈为了省电把 connection interval 拉到 100ms 以上，数据链路响应变慢，用户感知就是“信号不好”，其实是时延变大了。把 connection interval 和 slave latency 调到一个平衡点，比如 30ms 间隔加 2 次从机延迟，体感和功耗都还能接受。

5.4 配网失败率高，可能不是代码问题

配网体验差的一大部分原因是家庭路由器环境太复杂，跟代码关系不大。有些路由器开了 AP 隔离，设备连上 Wi-Fi 之后跟手机不在同一个网段，App 自然发现不了设备。有些路由器 5GHz 和 2.4GHz 共用 SSID，设备只支持 2.4GHz，用户在 App 里选了 Wi-Fi 名字但实际连的是 5GHz 频段，一样失败。解决方案是给用户更多指引，以及尽量采用 BLE 配网方式。BLE 配网不受网段和频段影响，App 只要在 BLE 扫描结果里点到设备，然后通过 BLE 通道把 Wi-Fi 账号密码传过去，设备再自己连接路由器，整个过程用户感知非常顺畅。这也是我一直建议能做 Combo 就做 Combo 的一个重要原因。

最后说点个人体会，我在做无线选型踩过最大的坑，不是参数选错，而是评估阶段太仓促。很多项目恨不得一周内把方案定下来，结果到了量产阶段才发现功耗、距离、共存、认证这些问题一个接一个冒出来。选型阶段多花一周做实测、做多方案对比，后面能省下两个月甚至更长的返工周期，这笔账算下来非常划算。希望这篇东西能让你少走一点弯路。