做IoT设备选无线方案这几年我最大的感受是很多人不是不会选而是被市场宣传带偏了。Wi-Fi 6出来之后几乎所有模组厂商都在推Wi-Fi 6 蓝牙Combo方案好像不支持Wi-Fi 6的模组就已经落后一个时代了。但实际落地时你会发现很多场景用Wi-Fi 4甚至BLE就绰绰有余而有些场景看似需要Wi-Fi 6真到了电池供电环节又根本撑不住。这篇文章我想从一个实际做产品的角度把Wi-Fi 6、蓝牙LE和Combo方案这件事彻底拆开聊一聊。不是念规格书而是结合我在智能家居、工业数据采集和可穿戴设备上的真实选型经历讲清楚三者的边界、取舍和坑。顺便把大家搜得最多的两个问题一并解决到底什么是蓝牙LE以及跑IoT系统的设备对无线方案有什么隐性要求。1. 先搞清楚一个根本问题你的设备到底在跟谁通信选无线方案之前第一件事不是比参数而是画清楚数据链路。IoT设备的通信拓扑看起来很简单实际上会直接影响选型方向。1.1 三类拓扑决定了方案的大方向最常见的拓扑是设备直连路由器或网关走标准IP网络。这类场景天然偏Wi-Fi因为路由器生态太成熟了手机、云端、局域网内互相访问都不需要额外硬件。第二类是设备直连手机点对点通信。典型例子是蓝牙耳机、运动手环、体脂秤。这类场景带宽要求低功耗敏感度极高BLE基本是默认答案。第三类是设备作为网关或中继既要向上连云端又要向下收集传感器数据。这个坑最容易踩很多人一上来就选一个单纯Wi-Fi 6模组结果发现还要多挂一颗BLE芯片去收传感器数据成本直接翻倍。这种场景其实最适合Combo方案。我见过太多案例需求文档里写的是智能门锁实际场景是门锁要接收手机蓝牙配置指令又要上报状态到云端还要支持远程开锁。如果你只选了Wi-Fi开锁延迟和配网体验就会非常糟糕只选蓝牙又没法实现真正的远程管理。这就是典型的Combo刚需场景。1.2 数据特征决定了对带宽和时延的真实需求第二个维度的判断依据是数据。我用一个非常直白的方式分类控制类数据几十字节到几百字节如开关灯、调节温度。对时延敏感对带宽几乎无感。状态类数据几百字节到几K如传感器上报、设备心跳。对可靠性有一定要求对带宽要求也很低。流媒体类数据几百K到几十M如视频监控画面、音频流。对带宽和时延双敏感。固件升级数据几百K到几十M瞬时的带宽消耗大户。如果产品以控制类和状态类为主盲目追求Wi-Fi 6的高吞吐并没有实际意义。Wi-Fi 6真正强的是高并发场景下的多设备调度能力而不是单设备的极限速率。这个后面我会详细说。2. Wi-Fi 6在IoT里的真实价值OFDMA和TWT才是主角很多人一听到Wi-Fi 6就觉得快这是被消费级路由器的宣传带偏了。Wi-Fi 6的家庭宽带应用场景和IoT场景完全不一样。在IoT里Wi-Fi 6的真正价值是OFDMA和TWT这两个特性。2.1 OFDMA解决的是多设备并发而不是单设备速度OFDMA的全称是正交频分多址本质上是允许路由器在一个信道里同时为多个设备服务。过去Wi-Fi 4和Wi-Fi 5时代设备之间是排队上网的哪怕你只是发送一个几十字节的心跳包也要占住整个信道一段时间。当家里的智能设备多起来之后信道利用率低的问题就会变得异常突出。我在实际项目里测过一组数据在一个有30台Wi-Fi设备的环境里Wi-Fi 4路由器下设备平均交互时延经常能到几百毫秒而Wi-Fi 6路由器配合支持OFDMA的模组时延能稳定在几十毫秒以内。这不是带宽提升带来的效果纯粹是调度效率的优化。所以如果你做的产品品类是灯泡、插座、传感器这类会在大规模组网中成批出现的设备选Wi-Fi 6的模组是有意义的。但如果设备数量不大单台设备的数据量也很小Wi-Fi 6的这个优势就体现不出来。2.2 TWT是IoT功耗真正的解药TWT全称是Target Wake Time目标唤醒时间。它允许设备和AP约定好一个时间表只在约定的时间窗口唤醒收发数据其余时间深度睡眠。这个机制对电池供电的IoT设备意义极大因为Wi-Fi一直被诟病功耗高根源就在于设备需要频繁监听AP的beacon帧而这种监听是非常耗电的。我在一个电池供电的温湿度传感器项目上做过实测对比。同样是一节CR2032电池每分钟上报一次温度传统Wi-Fi方案大约只能撑两到三周而支持TWT的Wi-Fi 6方案能做到三个月以上。功耗下降了不止一个量级。但这里有一个非常现实的坑TWT要生效不止是模组支持就行路由器AP端也得支持。如果你的产品要跑在用户家里的老路由器上TWT基本就是空谈。所以当时我给那个温湿度传感器做选型时最终没有冒险选纯Wi-Fi 6方案而是给客户提供了Wi-Fi 6 BLE Combo版本的备选——Wi-Fi 6负责将来在支持TWT的路由器环境里省电BLE则保证在老路由器环境下的实用性。2.3 Wi-Fi 6在IoT里的成本账成本是绕不开的话题。普通Wi-Fi 4模组大批量采购可以压到10元人民币以内Wi-Fi 6模组普遍在15到25元之间。对于消费级IoT单品来说这5到15元的差价会影响毛利。但从另一个角度看Wi-Fi 6模组近年来出货量暴涨价格已经比两三年前亲民很多了。如果产品有足够量级可以直接和模组原厂谈很多模组厂都愿意在新项目上给出贴近Wi-Fi 4的价格。还是那句话最终卡你的不是模组成本而是产品场景是否真的需要Wi-Fi 6。3. 蓝牙LE到底能干什么不能干什么蓝牙LE是Bluetooth Low Energy的缩写也就是低功耗蓝牙很多人搜蓝牙le是什么意思本质就是想搞清楚它和平常手机连的蓝牙有什么区别。一句话解释经典蓝牙BR/EDR重连续传输适合耳机和通话低功耗蓝牙重极低功耗和轻量交互适合传感器和按钮这种不常通信的设备。3.1 BLE的核心优势低成本、低功耗、低门槛BLE模组的成本可以做到5块钱以内是Wi-Fi方案的四分之一甚至更低。功耗方面一颗纽扣电池撑半年到一年很常见这是Wi-Fi目前难以做到的。BLE还有个独门优势是手机生态——所有主流手机系统都原生支持BLE不需要额外硬件开发门槛低配网体验也远好于Wi-Fi。举个例子很多智能家居设备第一次配置入网都是通过BLE把Wi-Fi的SSID和密码传过去。如果设备连BLE都没有用户就只能用热点方式配网体验极其痛苦。这就是为什么你会发现哪怕是纯Wi-Fi设备很多也会加一颗低成本的BLE芯片用来做配网。3.2 BLE的边界带宽、距离和网络拓扑BLE的不足之处也很明显带宽上限约2MbpsBLE 5.0之后的理论值实际有效吞吐量打五折都很正常。传输距离比Wi-Fi要短虽然BLE 5.1/5.2的远距离模式有提升但和Wi-Fi的覆盖能力相比还是有差距。网络拓扑上传统BLE是星型手机和传感器一对一连BLE Mesh虽然解决了组网问题但消息转发时延和可靠性还是比不上基于IP的Wi-Fi网络。我在一个室内定位项目里试过BLE Mesh方案它的优势是部署成本极低节点成本打到几块钱但遇到人流量大的场景时消息冲突导致时延不稳定最终我们还是改用了Wi-Fi方案。所以BLE适合轻量交互低功耗上报这种事情但对高并发、高实时性的场景会力不从心。3.3 BLE在工程化中的两个经验细节第一是广播的冲突控制。如果设备密度高BLE广播包会很拥挤这时需要动态调整广播间隔而不是固定在一个标准值。第二个是非常重要的经验当前很多扫地机器人、智能门锁带BLE其实是用来做近场调试和产线测试的。生产环节里用BLE刷参数比用Wi-Fi稳定得多因为Wi-Fi容易出现信号干扰导致产线不良率上升。这个细节在做方案选型时可以提前考虑省下的产线费用可能比你想象的要多。4. Combo方案的互补逻辑和隐藏成本既然Wi-Fi和BLE各有短板把两者集成在一颗芯片上的Combo方案就成了很多品类的热门选择。Combo的意义在于一个模组同时提供Wi-Fi和蓝牙既可以发挥Wi-Fi的高带宽和IP网络能力又可以利用BLE的低功耗和手机配网优势。这个方案要真正做好有几个隐蔽的坑需要注意。4.1 协议栈共用和天线设计是第一个坎Combo芯片里Wi-Fi和BLE虽然物理上是两颗radio但共享同一根天线和同一套协议栈调度。如果厂商的协议栈写得不够好蓝牙广播和Wi-Fi收发可能会互相抢占资源导致蓝牙连接卡顿或者Wi-Fi速率波动。我遇到过一款模组BLE长时间连接时Wi-Fi吞吐量下降了30%查下来就是因为共天线机制里BLE的接收窗口频繁插队。最后只能通过调整两者的共存优先级参数来做弥补浪费了不少时间。所以在选Combo方案时不能只看芯片参数还要看模组厂有没有把共存调校做过。这个没法从规格书上看到只能靠拿评估板实测。4.2 多射频共存时的调试复杂度Combo设备是多射频并存的多天线布局会引起相互干扰尤其是Wi-Fi 2.4G和BLE都工作在2.4GHz频段两者会互相干扰。虽然芯片内部有共存仲裁但板级设计也要注意BLE天线的净空区、与Wi-Fi天线的间距都会影响实际性能。PCB Layout上两条射频线要拉开足够的距离天线之间至少要保证十几毫米的隔离。有些项目为了追求体积把天线挤在一起结果BLE接收灵敏度直接掉了几个dB。这些坑都属于选型结束之后才暴露的问题最有效的应对办法就是在选型阶段就把PCB约束同步给结构工程师提前规避风险。4.3 功耗规划的复杂度会翻倍Combo方案的软件处理逻辑要比单射频复杂很多。Wi-Fi连接时怎么让BLE也休眠BLE在接收数据时怎么不让Wi-Fi频繁扫描信道这些都需要非常细致的状态机设计。我在一个智能门锁项目里吃过亏Wi-Fi和BLE同时开启后系统掉电速度比预期的快了一倍。排查下来发现是BLE一直保持可发现状态每隔几秒就广播一次导致系统从浅睡眠中反复被唤醒。后来把蓝牙配置成只在特定时间开启可发现功耗才恢复正常。所以Combo方案带来的功耗优化不是免费的它需要整体软件架构的配合。如果你团队里没有专门的无线协议栈开发经验我建议优先选那些原厂已经把功耗状态机封装好的模组不要自己裸调。5. 一张表看懂三类方案怎么选很多刚接触IoT选型的朋友最大的困惑是把参数对比当作选型依据。实际上 参数对比只是第一步更重要的判断维度是产品形态、功耗预算和部署环境。维度Wi-Fi 6蓝牙LEWi-Fi 6 BLE Combo典型成本中高低高峰值带宽高低高功耗表现中高依赖TWT极低中高可分层优化手机直连一般原生支持优秀配网体验一般优秀优秀大规模组网强OFDMA一般BLE Mesh有上限强产品体积中小较大适合品类摄像头、网关、智能音箱传感器、穿戴、门锁近场智能门锁、网关、全屋智能节点看完这个表你能发现Wi-Fi 6不是用来替代BLE的BLE也不是拿来跟Wi-Fi 6比带宽的。它们各管一段。有一段需要单独提醒如果你的产品有视频流需求不要指望BLE老老实实选Wi-Fi。如果你的产品是纽扣电池供电充满雄心壮志的Wi-Fi 6方案会让你的电池在几天内耗尽这时候BLE或者超低功耗的Wi-Fi 6平台才是正解。Combo则是我全都要但得付出成本和功耗代价的折中方案。6. 结合热词做一次系统软件层面的选型思考早期很多工控屏和商业终端会跑Win10 IoT Enterprise系统这类设备普遍需要Wi-Fi和蓝牙能力。那次在做选型对比时我发现win10 iot enterprise 2016 ltsb x64语言包下载是搜索热词反过来也说明了IoT设备系统层面的一个普遍问题——驱动和语言包等系统兼容性是选型时容易忽视的环节。6.1 IoT系统对无线方案真的有隐性门槛如果你做的是跑Windows IoT Enterprise的设备那选无线模组时需要非常小心驱动支持。很多小厂的Wi-Fi模组在Windows系统上没有官方驱动或者驱动版本老旧没法利用较新的无线功能。最终会导致你在模组上本来买的是Wi-Fi 6实际跑起来只有Wi-Fi 4的体验。我的建议是在选型初期就去模组厂的官网把所有操作系统对应的驱动包拉下来实测尤其是Win10 IoT Enterprise这种较老系统的LTSB版本新模组有时反而不如成熟的老型号兼容性好。这个坑在用户现场很难排查因为看起来是无线问题其实是驱动适配问题。6.2 开发板选型时也要看系统工具的生态适配另一个容易忽略的点是可维护性。很多IoT设备要支持后期远程升级如果系统是Win10 IoT Enterprise你选择的无线方案得要有稳定可靠的驱动升级通道否则一旦系统封装了固定版本驱动后续Wi-Fi协议栈的兼容性升级就会很麻烦甚至只能返厂。这种问题做消费级小家电的同行可能体会不深但一旦做商用设备设备生命周期五年起步系统级的无线方案就成了重要全局决策关系到后续维护成本。6.3 我的建议顺序先看产品是否需要跑重型系统再决定选Wi-Fi 6还是BLE还是Combo。跑系统且需要持续在线优先Combo跑系统但只是偶尔同步数据纯Wi-Fi即可跑系统同时又要求低功耗常待机那就得往前选BLE配合不能指望用系统设备低功耗待机。7. 三个实际落地案例从选型到量产的完整复盘理论说再多不如直接看几个案例的复盘。这三个项目覆盖了三种完全不同的选型路径算是我这些年做IoT无线方案选型最典型的三种走法。7.1 案例一智能门锁的Combo方案项目背景是联网智能门锁需要支持手机近场配置、远程上报门锁状态、接收远程开锁指令同时要求两颗AA电池续航半年以上。一开始我们的想法是远程开锁必须走Wi-Fi所以选定一个Wi-Fi 6模组搞定全部通信。结果实测发现Wi-Fi保持连接时功耗非常高电池根本撑不到一个月。后来改为Wi-Fi 6 BLE Combo方案平时Wi-Fi处于深度睡眠状态只保持BLE可扫描手机靠近时通过BLE完成开锁和参数配置只有需要远程控制时才唤醒Wi-Fi连接路由器。彻底解决了功耗问题。这个项目还踩了一个天线的坑门锁金属外壳对Wi-Fi天线的屏蔽效应很强一开始把天线贴在电池仓附近信号室测下来衰减超过10dB。后来把天线引到前面板的非金属区域信号才恢复正常。这个经验对门锁类产品特别重要选型时一定要把天线位置纳入整机结构考虑。7.2 案例二楼宇温湿度传感器为什么从Wi-Fi降级到BLE另一个项目是楼宇里的温湿度传感器每个房间布置十个一栋楼至少几百个点。最初客户指定要Wi-Fi方案原因是IT部门希望统一走公司网络管理。但部署测试后发现几百个设备同时连接企业AP信道冲突严重且设备多带来的管理负担远超预期。最终改为BLE方案每层楼放一到两个BLE网关传感器通过BLE接入网关再由网关走有线/以太网上云。好处是传感器功耗极低网关数量可控网络部署问题大大简化。虽然多了网关成本但整体系统稳定性反而大幅提升。这个案例说明选型不是只选模组而是设计整个网络拓扑。7.3 案例三带屏网关从Wi-Fi 4升级到Wi-Fi 6第三方合作项目是一个厨房带屏网关屏幕需要显示云端菜谱、音乐和视频通话并发数据量大而且会有多个屏幕同时在线。过去用Wi-Fi 4模组视频通话老卡顿但也不是完全不能用只能说是勉强能跑。升级到Wi-Fi 6之后同样的网络环境下视频通话流畅度明显改善而且同区域多台网关同时使用时相互之前的资源抢占问题也缓解了很多。这就是Wi-Fi 6高并发价值最直观的体现——它不是让单台设备飞起来而是让整个空间里的多台设备都不打架。8. 选型决策流程从需求到方案的完整链路最后我把完整的选型决策流程整理成了一套可以照着走的步骤。每个环节都标注了我的经验和踩坑心得。8.1 步骤一列出产品的非功能需求清单开始看模组之前先回答这几个问题产品是电池供电还是市电供电如果是电池供电目标续航是多久是否需要远程管理和固件升级如果需要升级数据量有多大是否支持手机直连配网体验的期望等级是怎样的设备部署数量级是多少是否有大规模并发的可能产品生命周期多长是否有系统级的长期维护需求这些问题的答案会直接帮你排除掉一批方案。如果产品是电池供电且追求超长续航Wi-Fi 6方案基本上可以直接不看了如果产品是市电供电且有大带宽需求BLE直接排除。8.2 步骤二根据需求清单选出两到三个候选方案不要只盯着一个方案看尽量保持两到三个候选。比如Combo方案里可以挑两家不同模组厂的产品做备选如果纯BLE可行再准备一个BLE方案做对照。这样做的好处是可以拿实测数据推翻自己的假设。我几乎每个项目都试过原以为最优的方案在实测中翻车所以现在形成习惯候选方案永远不止一个而且一定要做实测验证不能只看规格书。8.3 步骤三搭建实测环境验证关键指标实测环境很关键因为有很多指标只有在模拟真实场景时才能测出来传输速率和实际吞吐量一定不要相信厂商标称他们的测试环境是在实验室无干扰前提下。拿到评估板后在办公室或现场环境去测实际吞吐量。时延稳定性持续压测半小时以上记录时延的抖动范围。功耗曲线用电流探针记录设备工作的完整电流曲线覆盖不同工作模式。共存干扰Wi-Fi和BLE同时开启观察双方表现是否有明显下降。系统兼容性如果跑Win10 IoT Enterprise这类系统直接在目标系统上跑一轮压力测试。8.4 步骤四和模组厂深入沟通量产细节量产阶段的坑往往在选型阶段埋下的。需要确认的事包括价格阶梯、交期稳定性、模组认证情况SRRC/FCC/CE等、 原厂技术支持力度。还有一个容易被忽略的模组吞吐量和天线引脚的阻抗匹配是不是需要定制天线。有些项目为了外观天线必须做得很小这时候就要跟模组厂确认信号链路预算是否还够。8.5 步骤五把方案做进产品再验证千万不要只停留在评估板跑通了这个阶段。评估板跑通和整机性能达标完全是两码事。一定要在整机结构定型后打样几台做一次全功能实测。实测内容包括天线在整机中的性能表现、金属外壳和环境对射频的影响、多台设备互相干扰的情况、系统老化后的稳定性。这一步最常见的坑是评估板测试全部通过整机一装起来蓝牙连不上Wi-Fi掉线因为结构设计把天线位置挤没了。所以整机验证要做而且要在结构定型之前就做不然改结构会非常痛苦。9. 后续扩展方向把无线选型做成一项竞争力选型不是一次性的工作。产品会迭代芯片会更新市场也会变。在第一个版本落地之后我得到的最大教训是把无线选型的决策依据文档化形成自己团队的标准选型checklist比记住某个最佳方案更有价值。每做完一个项目我都会更新一遍自己关于功耗、成本、带宽、组网难度等方面的认知表格。随着Wi-Fi 6普及、BLE的演进以及将来Wi-Fi 7、UWB这些新技术的出现这份决策依据能让我在新一轮选型时心里更有底。如果时间允许我特别建议做一次反向验证把过去项目中因为选型失误导致的问题回看一遍你会惊讶地发现很多问题是可以在选型阶段就提前规避的。这些复盘经验才是做IoT产品最有价值的积累。