做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的不足之处也很明显：
- 带宽上限约2Mbps（BLE 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 | 蓝牙LE | Wi-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产品最有价值的积累。
