企业官网建设流程全解析

最近接了个智能门锁的项目，主控芯片选型倒是没费太多功夫，整个团队却在无线方案上吵了两周：走 Wi-Fi 6 直连、用蓝牙 LE，还是一步到位上 Combo 模块？三家方案商给的参考设计都很有道理，评审会开完一轮又一轮，最后靠拆了几台竞品机才把方向定下来。这种纠结，做 IoT 产品的朋友应该都不陌生。Wi-Fi 6、蓝牙 LE、Combo 组合方案这三条路线，基本覆盖了目前消费级和工业级 IoT 设备能在 2.4GHz 频段用到的所有主流无线选择，但每一条路都远没有名字看上去那么简单。这篇文章会把自己做选型时的思考框架和踩坑记录完整拆开讲一遍：Wi-Fi 6 的 TWT 到底能把待机功耗压到多少，蓝牙 LE 在哪些场景会撞上吞吐天花板，Combo 模块的真实成本与 2.4GHz 共存问题怎么解。不管你是刚入行的嵌入式工程师，还是要拍板硬件方案的产品负责人，希望这份梳理能帮你把一道选择题变成填空题。

1. 选错无线方案的代价：为什么项目立项时最该先碰这个

1.1 三个我真实见过的翻车场景

先说第一个，一个做环境监测传感器的团队，为了图省事，全系产品都用了一个老款 Wi-Fi 模组。CR2032 纽扣电池理论上标称能用一年，实际上每 10 分钟上报一次温湿度，两个月就掉到 20% 以下。Wi-Fi 从连接、保持关联到 TCP/TLS 建连、HTTP 上传，每一环都在消耗电流，那 10 分钟一次的唤醒看上去频率不高，但一次完整上报的峰值电流 100mA 以上、持续时间 1 到 3 秒，折算到平均功耗上非常恐怖。选型时只盯着峰值功耗低，没算平均功耗，这是最常见的坑。

第二个方向相反，一个做宠物喂食器的团队坚持全 BLE，理由是低功耗、成本低。结果产品要在没有网关的情况下支持手机远程查看剩余粮量，甚至摄像头抓拍，蓝牙 LE 那点吞吐传一张图要磨蹭十几秒，用户真实体验奇差。

第三个是 Combo 的翻车。做智能音箱的团队在 Wi-Fi 和 BLE 同时开启时蓝牙音频断断续续，查到最后是模块内部两个射频共享天线却没有做好共存仲裁，Wi-Fi 一忙就把 BLE 的连接事件挤掉了。这三个例子有一个共同点：三类方案本身都没毛病，问题出在选型时只考虑"这一项技术能不能实现需求"，没有把功耗预算、吞吐需求、射频共存、认证排期和供应商能力放一起算总账。

1.2 无线方案牵一发而动全身

无线选型影响的绝不只是那一颗模组。它直接决定你用什么样的系统电压和电池拓扑，决定 MCU 需要多大的 RAM 和 Flash 去跑协议栈，决定产品要过哪些认证、周期多长，决定 APP 是走局域网直连还是要云平台中转，决定 OTA 升级是 10 秒完成还是让用户等十分钟。换句话说，越到后面才发现无线方案选错了，推倒重来的成本就越高。立项阶段花一天把选型框架拉清楚，比打样之后再回来改，便宜十倍不止。

2. Wi-Fi 6 在物联网里的真实角色：不是快，而是省与密

很多人一听 Wi-Fi 6 的第一个反应是"快"，那是手机、路由器的语境，是跑测速、看 4K 视频的语境。在 IoT 设备上，Wi-Fi 6 能带来的核心价值其实是另外三个词：省电、抗拥塞、安全合规。这三个词决定了它跟老 Wi-Fi 模组的本质区别，也正是它们让"IoT 用 Wi-Fi 6"从"杀鸡用牛刀"变成了一种合理选项。

2.1 TWT：把待机功耗从"小时级"拉到"周级"的关键

TWT（Target Wake Time，目标唤醒时间）是 802.11ax 引入的机制。传统 Wi-Fi 的省电模式靠 DTIM Beacon 周期唤醒，即使没数据也要定时醒来听 AP 的指示；TWT 则允许设备和 AP 协商一套明确的唤醒时间表，设备可以在绝大部分时间深度睡眠，只在约定的时间窗口醒来收发数据。

我做过一个很粗的估算：假设某低功耗 Wi-Fi 6 模组在唤醒窗口内接收平均电流 60mA，窗口长度 60ms，如果 TWT 间隔设为 1 秒，平均电流约 3.6mA；间隔拉到 10 秒，平均就降到 0.36mA 左右；再加上深度休眠时微安级的静态功耗，一节 220mAh 的 CR2032 理论上能维持数十天到上百天。当然，实际续航还会受重连、关联保活、TCP keepalive、固件更新等因素影响，不可能只按这一个公式算，但量级感就是从这里来的。

提示：TWT 的收益强依赖路由器/AP 侧是否支持。如果目标用户家里还是三年前的老路由，设备会自动回退到普通省电模式，TWT 等于没开。所以做消费类产品时，要么在需求里明确"建议搭配支持 Wi-Fi 6 的路由器"，要么在固件里做降级兼容逻辑，不能用 TWT 去赌所有用户的环境。

2.2 OFDMA 与高密度场景：一屋几十个设备不再打架

IoT 设备密集部署时的体验，很大程度上取决于信道效率。最早的 Wi-Fi 是"排队发言"的 CSMA/CA 机制，几十台智能家居设备连到同一台 AP，靠随机退避来避让，设备一多，碰撞、重传、等待都会堆起来。OFDMA 把信道细分成了多个资源单元（Resource Unit），AP 可以在同一个时间片里调度多台设备并行传输。对低速率、小报文的智能家居设备来说，这相当于把一条单车道改成了多车道并行，延迟和功耗都能得到改善。

配合 BSS Coloring 做空间复用、MU-MIMO 做多用户并发，Wi-Fi 6 在"大量设备接入同一 AP"的场景里优势非常明显。这也是为什么现在做智能门锁、家庭中心、多传感器套装这类产品，路由器一升级到 Wi-Fi 6，整体连接稳定性肉眼可见地变好。

2.3 WPA3 与 Matter：认证和安全上的硬门槛

Wi-Fi CERTIFIED 6 强制要求支持 WPA3，这是很容易被忽略的点。WPA3 用 SAE 替换了 WPA2 的 PSK 四次握手，针对离线字典攻击的防护更好。很多老产品用的 WPA2-PSK 在暴力破解面前已经有点吃力，消费用户可能没感知，但采购名单和运营商准入清单卡得很严，尤其在北美运营商渠道，设备不支持 WPA3 往往直接进不了准入名单。

另外，Matter 协议把 Wi-Fi 和 Thread 作为主要的 IP 层传输，同时要求 Matter 设备在配网阶段使用 BLE 进行发现和配网。这意味着如果你的产品要打 Matter 标，除了运营 Wi-Fi，大概率还缺不了一颗支持 BLE 的协处理器或 Combo 模块。这也是 2024 年以后很多 Wi-Fi 产品设计图上多出 BLE 的原因。

2.4 Wi-Fi 6 真正适用的 IoT 品类

选 Wi-Fi 6 单模的时候，我会先问三个问题：设备是否持续供电或至少能经常充电？单次上报或串流的数据量是否明显超过几百 KB？是否必须通过路由器/云平台访问而不是手机直连？三问都打勾的，才适合纯 Wi-Fi 路线。典型品类是 IP 摄像头、可视门铃、智能音箱、家庭网关、工业数据记录仪。靠纽扣电池的低速率传感器，在绝大多数情况下都不该走这条路。

3. 蓝牙 LE：适合跑得更久，但要知道它的三块短板

3.1 先厘清概念：蓝牙 LE 不是"低功耗版蓝牙"那么简单

经常有人搜"蓝牙 le 是什么意思"，其实这个命名本身就容易误导。BLE（Bluetooth Low Energy）并不是传统蓝牙（BR/EDR）的低功耗版本，它在 4.0 时代就是一套全新的协议栈，物理层和链路层都重新设计过，只是同属蓝牙 SIG 的伞形体系。它跟经典蓝牙不能直接互通，一个设备如果只有经典蓝牙，另一个只有 BLE，二者是聊不上的。所以做选型前先搞清楚自己对标的到底是 4.0/5.x 的 BLE，还是老式经典蓝牙，这是第一层。

BLE 从 4.0 一路走到现在，每一代都在为低功耗、低成本设备增加能力：5.0 带来 2M PHY（速率翻倍）、Coded PHY（距离更远）和扩展广播；5.1 加入 AoA/AoD 方向定位；5.2 定下 LE Audio 和增强版 ATT；5.4 则推出 PAwR 和电子价签（ESL）profile，让海量低频、低成本标签设备有了标准化的低功耗连接方式。

3.2 速率、距离与并发：三个数字帮你定边界

BLE 物理层最高是 2Mbps 的 2M PHY，但那是空口速率，经过协议栈、GATT/ATT、数据分片和重传以后，应用层实际吞吐通常落在 50 到 800kbps 区间。一个很直观的例子：给设备做 OTA，如果固件是 1MB，按比较理想的 200kbps 应用层吞吐算，也要 40 秒以上，用户压根等不住。一旦业务里有"频繁传图、传音频、传大文件"的需求，BLE 就不是主力通道，只适合做配网和低频控制。

距离方面，Coded PHY 能提升接收灵敏度，理论上可以把范围拉到几百米，但实际室内隔墙后的表现要打折，多数 BLE 设备在室内稳定覆盖也就 20 到 50 米。更重要的其实是并发和角色模型：手机这类 Central 设备连接数量有限，几台到十几台基本是极限；而 Peripheral 只能被一个 Central 连接。想要一屋子几十个传感器自发并行通信，BLE 点对点就不好使了，需要 Mesh 或者广播加周期响应的机制来兜底。

3.3 BLE Mesh 的适用场景与翻车现场

BLE Mesh 基于泛洪，消息靠转发节点一级级广播扩散，优点是基础设施简单、节点可以很便宜，缺点是广播风暴会造成时延不确定和大网络带宽浪费。适合的是"大量节点、低频次、小消息"的控制类场景，比如全屋灯光、窗帘电机、楼宇传感网。不适合的是需要稳定低时延、大数据量或频繁双向交互的场景。

我之前看过一个团队用 BLE Mesh 做会议室预约面板的集中管理，几十个节点每 5 秒做一次全局状态同步，结果高峰期消息风暴把整个网格拖到卡顿。后来改成每个面板单独连 BLE，或者只用广播上报状态，Mesh 只保留关键的开关指令通道。所以不要被"Mesh 万能"的错觉带跑，先估消息量和频次再决定要不要上。

3.4 手机生态与免路由器：蓝牙独有的交付优势

BLE 的不可替代性，很大程度来自手机生态：安卓和 iOS 底层都原生支持 BLE，不需要配路由器密码，不需要搞复杂的配网流程，手机扫码或者靠近就能完成配对和密钥交换。对消费类产品来说，这意味着激活流程、离线配置、设备本地面板控制都能在"无网环境"下完成，这是 Wi-Fi 做不到的。

价格账也要算进去：一颗纯 BLE SoC 的成本通常只有 Wi-Fi SoC 的 1/2 甚至 1/3，功耗还低一个量级。所以很多出货量大的小家电、体脂秤、温湿度计，默认就是 BLE，不是设计者保守，是成本和体验综合下来确实最合理。只要业务不碰高带宽，BLE 永远是那个"不会得罪人"的底牌。

4. Combo 方案：两全其美的代价与工程真相

4.1 Combo 模块的典型架构与工作模式

Combo（也叫 Combo SoC/模块）就是把 Wi-Fi 和蓝牙 LE 集成到一颗芯片或一个模组里，共享射频前端、晶振和天线，通过内置固件协同调度。目前市面上像乐鑫 ESP32-C6（Wi-Fi 6 + BLE 5.0 + 802.15.4）、Silicon Labs 的 SiWx917（Wi-Fi 6 + BLE 5.1）、NXP 的 RW612 这类方案，已经可以在低成本的两层板上同时提供 Wi-Fi 6 和 BLE。

工作模式上有两种常见形态：一种是"轮换模式"，同一时刻只让一个协议工作，哪个协议需要发送就切谁，适合低频业务；另一种是"并发模式"，两个协议交替抢占射频时间片，BLE 的 connection event 到了要发，Wi-Fi 的帧也要发，由底层仲裁逻辑决定谁先谁后。芯片设计越成熟，这种并发切换的效率和丢包控制就越好。

4.2 同频射频共存：2.4GHz 上的打架问题怎么解

既然 Wi-Fi 和 BLE 都跑在 2.4GHz，二者在同一颗芯片上同时工作，本质上就是在一个公共频段上抢空气。如果不做协调，Wi-Fi 一广播，BLE 的接收灵敏度就会被压下去，表现为连接事件丢失、重传率升高、功耗上涨，严重的时候蓝牙音频断断续续。

工程上常见的手段有三类。第一类是 PTA（Packet Traffic Arbitration），用专用引脚把两个协议栈的优先级信号交给射频前端仲裁，比如 BLE 的连接事件优先级最高，Wi-Fi 让它先发；第二类是时间片划分，把某个时隙固定给 BLE，其余时间给 Wi-Fi，适合能接受一定延迟的产品；第三类是用双天线分开走，代价是成本和体积。实际量产项目里 PTA 是绝对主流，但 PTA 的配置很考验模组厂商的 SDK 成熟度，这也是选模块时要重点压测的项目。

提示：做 Combo 产品联调时，一定要专门做一个"高负载混合测试"：让 Wi-Fi 满速下载和 BLE 连续数据交互同时跑，观察丢包、时延和模块外壳温度。很多模块单跑一个协议很稳，两个协议叠满就露馅，这个问题在评审文档里往往不会写。

4.3 智能门锁、健康监测仪、白色家电：谁适合 Combo

我判定要不要上 Combo，通常会看"设备是否同时需要两类截然不同的连接能力"。智能门锁是最典型的：平时锁芯主控靠 BLE 做低功耗侦听和手机靠近解锁，平均电流能压到几十微安，撑两年没问题；同时它又需要 Wi-Fi 去上报开门记录、远程下发临时密码、执行 OTA 升级。这两类需求一个要"极低功耗常驻"，一个要"高带宽短突发"，任何单一协议都覆盖不全，只能 Combo。

健康监测类产品同理：体脂秤、血压计、血糖仪平时数据量很小，用 BLE 对接手机 APP 很舒服，但如果要接健康云平台、让子女远程看数据，还是得借 Wi-Fi 的通道。白色家电更倾向于"本地 BLE Mesh 组网 + 网关统一 Wi-Fi 上云"的分层架构，这种形态下家电本体用 BLE 或者单模也够；但若想省掉网关、让每台家电直连云平台，就得 Combo。组合方案的本质是"把选择权留给用户和环境"，代价是成本、功耗和调试复杂度都比单模高一档。

4.4 成本、认证与开发资源的真实账

成本上，一颗 Combo SoC 的价格大致是单模 Wi-Fi 模组的 1.2 到 1.8 倍、纯 BLE 模组的 2 倍以上。表面看差几块钱，对出货几十万台的消费单品来说，就是百万级的成本差异。认证层面，Combo 模组要同时走 Wi-Fi 和蓝牙两套认证体系，排期几乎翻倍，还要考虑两套天线底噪互相干扰的杂散测试。从软件上看，同时维护两套协议栈、处理两个协议共用 buffer 和任务调度的复杂度，也不是单模项目能比的。所以 Combo 不是"加个模组"那么简单，建议立项时把多出来的 4 到 8 周研发周期和至少 1 名专职无线工程师算进排期。

5. 一套可复用的选型决策表：把需求量化成指标

5.1 四维拆解法：功耗、带宽、成本、生态

抛开供应商 PPT，选型最终要回到四个可以量化的维度。

第一是功耗预算。先定电池容量和期望寿命，反推平均电流预算：比如 CR2032 是 220mAh，想要撑满两年，平均电流必须低于 220000uAh/(24×365×2)h ≈ 12.6uA。这个 12.6uA 同时毙掉了"纯 Wi-Fi 周期上报"和"BLE 持续常连"两类设计，除非业务允许设备绝大部分时间深度休眠。这个简单的除法，能把很多不切实际的方案直接筛掉。

第二是带宽需求。估一下单位时间内最大的瞬时数据量，以及这种高负载出现的频率。持续高于 1Mbps 的业务，比如视频流、批量文件传输、多路音频推流，基本只有 Wi-Fi 或者 Combo 里的 Wi-Fi 通道能做；长期只有几十 kbps 甚至更低、单次报文也就几十到几百字节的，BLE 就够；处于中间地带、且数据是周期性小报的，Wi-Fi 6 配合 TWT 的低功耗模式也能接受。

第三是成本预算。芯片成本只是起点，天线、滤波器、隔离器件、屏蔽罩、认证测试、云端流量、售后 LOG 排查，每一项都要摊进物料和运营成本。高端旗舰可以承受 Combo 的溢价，百元以内的普惠智能家居单品，很多硬指标是按供应商 BOM 表一张张卡下来的，多三块钱都过不了立项会。

第四是生态位置。设备在用户家里到底扮演什么角色：是直接被手机操控的终端，还是被当成网关/中心来中转数据？要不要兼容 Matter、Siri、Alexa、小爱这些平台？平台的接入门槛不一样，协议选择就会不一样。尤其当产品要进入别人的生态链时，很多决定权其实不在你手里。

5.2 典型品类的推荐方案矩阵

我把过去几年评审过的品类做了一个大致矩阵，供参考。

这个矩阵不是绝对的，但可以作为一个讨论起点。同一个品类，不同品牌策略（走量还是走高端）也可能切换方案。

5.3 给无线模块供应商的三个加分项与三个减分项

选型到供应商层面，我一般只看三件事。加分的是：SDK 与工具链完善，sample code 覆盖常见协议组合场景；模组在目标频段和温度范围内的实测数据透明，尤其有共存压测报告；器件的生命周期管理做得好，敢承诺多年供货。减分的是：文档东一榔头西一棒槌，技术支持响应靠销售转达；参考设计只给最短链路，天线、匹配、滤波全让客户自己踩；以及很重要的一条——模块厂商对"低功耗深睡电流"和"共存并发"这两项指标含糊其辞，这不代表没有问题，只代表他们不敢写清楚。

6. 量产之前必须补的课：认证、天线、OTA 与工具链

6.1 认证与合规清单

认证是硬排期，建议立项当天就排进去。Wi-Fi 产品通常需要过各销售区域的无线电和网络安全认证：北美 FCC、欧盟 CE/RED、日本 MIC 或 TELEC、国内型号核准 SRRC，具体清单以目标市场和模组厂商的集成认证状态为准。蓝牙侧则要走蓝牙 SIG 成员的资格认证（Declaration ID）。这些认证周期从几周到几个月不等。模组如果已经拿了模块级认证，整机认证会简化不少，但天线无源指标和杂散发射测试仍然要过自己的那一轮。做海外运营商项目的话，还会叠加运营商准入测试，这一项经常卡在最前面。

6.2 天线设计与外壳耦合：打样阶段最容易忽略

天线是"选型时一眼带过、实测时崩溃最多"的环节。同一颗模组用原厂参考板测试，灵敏度能做到 -95dBm，换到你自己的紧凑 PCB，又被塑料外壳和电池盖一围，直连态灵敏度可能掉 5 到 10dB，隔墙就从稳连变成频繁重连。所以打样阶段务必做三件事：一是留天线净空和参考地的仿真确认；二是做至少两版不同位置的 PCB 天线或 IPEX 外置天线对比；三是在整机状态（带电池、带金属件、带外壳涂层）下测吞吐和回退，别在裸板上测完就签字。

我自己就吃过亏：一款手持设备，天线底下铺了一条完整的 GND 铜皮，裸板还挺好，装上双面胶和外壳后吞吐直接腰斩。后来把天线区域的铜皮开窗、改 Y 型地枝匹配，又调了 π 型匹配网络才算回来。这类问题在校准和认证之前发现，成本是最低的。

6.3 OTA 与设备管理平台对接

无线方案定了，OTA 通道怎么走也要提前想。BLE OTA 适合小体积固件（几十到几百 KB）和低频更新，Wi-Fi OTA 适合全量镜像和快速批量升级。Combo 产品常见的做法是：平时 BLE 负责监控告警和参数小改，Wi-Fi 负责整包升级，再配合双分区、签名校验、断点续传和失败回滚。另外，设备上云之后要在物联网平台侧把设备影子、OTA 任务、日志上报和远程诊断接口一并设计好——很多项目固件写完了才开始想平台接口，结果为了塞数据反复改协议，非常痛苦。

6.4 我和团队在联调阶段踩过的几个具体坑

第一个是"手机并发连接"的假象。调试时同事用自己手机连设备，一下连了好几个 BLE 外设，模块这边看着像断连，其实是手机作为 Central 设备能维护的连接数有限，部分老机型只有 7 个左右。这是平台限制，不是模块 bug，排查前先把自己手机上的海量连接清出去。

第二个是电流测量的精度容易被忽略。低功耗产品测深睡电流，普通万用表根本抓不到微安级的脉冲，要用积分电流计或者示波器配低噪声电流探头，再配合触发模式专门看唤醒窗口的波形。不然你会把模块正常工作的几十毫秒电流尖峰当成异常，白白调三四天。

第三个是 Combo 的共存优先级在低电量下会退化。某些模块在电池电压低于阈值后，会在降电流模式下自动降低 BLE 的发射功率或调长连接间隔，导致门锁开锁响应变慢。这类 firmware 行为文档里往往不会写全，必须拿整机实测一遍低电量场景。

第四个是"参考设计好看，升级路径难"。有些模块只给了最小系统，不考虑后续要加 PA/LNA、加第二个频段或换天线，等量产发现信号不够想升级方案，整个 PCB 都要重画。所以选模块时最好同时问一句：这颗料往后一两代能不能 pin-to-pin 兼容，这决定了你这个产品能迭代几版。

最后说一点个人体会：无线选型这件事，本质上是把"产品定位、功耗预算、用户环境、运营成本"四个变量同时放在一张表里算平衡，而不是技术栈 PK。我见过很多团队在 Wi-Fi 6 和 BLE 之间反复比参数，最后发现卡住他们的其实是 OTA 时间太长、认证排期不够，或者是用户家里路由器太老。把这些落地问题前置到选型阶段，比花两星期争论协议优劣高效得多。下次再拿到立项需求，不妨先做一件事：把平均电流预算按公式算出来，把最大单次数据量写下来，然后你会发现，答案往往已经自己浮出水面了。