先说一个很多人在选型会议上容易踩的坑谈起“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 芯片和模组的实际表现不是理论峰值。维度Wi-Fi 6蓝牙 LEComboWi-Fi BLE数据吞吐高实测几十 Mbps 到上百 Mbps低BLE 5 单链路约 1-2 Mbps按 Wi-Fi 部分算蓝牙仅作控制和配网典型功耗连接态较高约几十到上百 mA睡眠后靠 TWT 优化极低连接态几 mAsleep 可以做到 µA 级Wi-Fi 部分同 Wi-FiBLE 部分同 BLE传输距离远室内几十米取决于 AP 和天线中短室内 10-30 米常见远因为 Wi-Fi 部分决定上限网络结构通过路由器接入局域网和云点对点手机直连或通过网关桥接既可以连路由器也可以手机直连配网体验一般要配 Wi-Fi 账号密码常用 SoftAP 或 SmartConfig好手机 App 直接扫描广播包配对最好BLE 配网 Wi-Fi 数据通道典型产品智能摄像头、音箱、家电联网版门锁、传感器、追踪器、遥控器智能门锁带摄像头、高端家电、Matter 设备模组成本中等偏高最低最高但低于两颗独立芯片之和这份表格解决的是“大方向”问题。举个例子如果你看到表格里“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 系统级支持 BLEApp 可以直接扫描、连接、收发数据不需要额外的硬件网关。这让 BLE 在“手机直连”场景里几乎没有对手也是智能门锁、蓝牙标签、健康手环全部采用它的根本原因。2.3 Combo 方案的底气1 1 不只是等于 2Combo 模组本质上是在一颗 SoC 或一个模组里同时集成 Wi-Fi 和蓝牙协议栈。我最早接触 Combo 是在智能音箱方案里当时觉得纯粹是“因为要做配网所以顺便焊一颗蓝牙”后来才意识到 Combo 的价值远不止省一颗芯片那么简单。第一层价值是共享射频前端和天线。一颗 Combo 模组可以用一根天线通过内部开关或双工器在不同时间片里跑 Wi-Fi 和蓝牙PCBA 上天线净空区只需要留一处这对体积敏感的产品太重要了。如果买独立 Wi-Fi 和独立 BLE 两颗芯片就要两套匹配电路、两根天线板子面积和调试工作量直接翻倍。第二层价值是软件协议栈的耦合。Combo 芯片内部一般会有专门的共存机制PTAPacket 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 字节”。下面是之前做一个智能门锁时整理的需求表可以用来参考需求字段产品定义对无线方案的影响供电方式4 节 AA 电池目标续航 12 个月平均电流必须小于 mA 级BLE 优先本地控制手机 App 蓝牙开门响应 3 秒必须有 BLE低延迟连接参数远程告警有人按门铃时把照片推到手机需要 Wi-FiBLE 传图太慢固件升级OTA固件包 600KB每月一次需要 Wi-FiBLE 升级体验太差产测要求生产线上快速识别并配置设备BLE 广播对产测最友好认证目标国内 SRRC 蓝牙 SIG选择已认证模组可引用报告填完这张表之后结论已经非常明确这颗智能门锁几乎必须是 Combo 方案BLE 负责开门和控制Wi-Fi 负责照片和 OTA。如果非要省钱去做单 BLE那远程看照片这个核心卖点就没了产品定义本身要改。4.2 拿到评估板后的第一轮无线实测评估板到手之后别急着跑 demo 程序先把四件事测完RX 灵敏度、TX 功率、实际吞吐量、以及低功耗模式的 sleep current。这些数值会直接决定方案能不能落地。RX 灵敏度和 TX 功率可以用综测仪或者通过板厂提供的软件工具来看。没有综测仪的话粗略一点就用两个评估板对拉看距离拉多远开始掉包。吞吐量用 iperf3 打流测 Wi-FiBLE 可以用手机或者另一块板子做连续大包传输测试。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. 常见问题与排查技巧实录最后整理一些我在实际项目里反复遇到、并且有明确排查思路的问题。这些问题在芯片官方文档里很难直接搜到完整答案但项目现场几乎每天都会碰到。现象根本原因排查方向解决建议BLE 和 Wi-Fi 在同一模组时互相干扰2.4GHz 共存冲突看 BER、丢包率是否随另一协议流量增加启用 PTA 共存机制或错开信道写着低功耗电池还是很快没电软件没进 sleep或唤醒过于频繁用功耗分析仪抓电流曲线看基线电流检查连接参数、DTIM 间隔、周边任务唤醒源BLE 连接距离比规格书短很多天线净空区不足、匹配电路不对、连接参数过紧测 S11、检查 PCB 天线区域、拉距测试不同手机结构调整天线连接间隔适当放宽BLE 传输偶尔很慢、甚至断开连接事件被 Wi-Fi 的流量挤压观察不同 Coex 策略下的表现调整 PTA 优先级给 BLE 预留时隙Wi-Fi 配网失败率高路由器隔离客户端、5GHz/2.4GHz 不分、App 兼容性问题抓配网日志换多台路由器对比改用 BLE 配网或兼容 SoftAP 兜底待机功耗单独测正常系统里却飙高传感器、LED、电源芯片的漏电叠加逐模块断开测电流做整机功耗分解找漏电大户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 的一个重要原因。最后说点个人体会我在做无线选型踩过最大的坑不是参数选错而是评估阶段太仓促。很多项目恨不得一周内把方案定下来结果到了量产阶段才发现功耗、距离、共存、认证这些问题一个接一个冒出来。选型阶段多花一周做实测、做多方案对比后面能省下两个月甚至更长的返工周期这笔账算下来非常划算。希望这篇东西能让你少走一点弯路。