2、无线配网协议对比：Wi-Fi、BLE、Zigbee、LoRa、NB-IoT在休眠场景下的功耗差异

做物联网产品选型，最头疼的就是挑无线协议。尤其是做电池供电的设备，休眠功耗直接决定了产品能活几个月还是几年。

我这些年经手过不少项目，从智能门锁到环境传感器，几乎把主流协议都踩了一遍。今天咱们就掰开揉碎，看看 Wi-Fi、BLE、Zigbee、LoRa、NB-IoT 这五兄弟，在休眠场景下到底谁更省电。

2.1 为什么休眠功耗差异这么大？

说白了，无线芯片在休眠时，功耗主要取决于三件事：

• 射频前端能不能彻底断电——有些协议必须保持定时唤醒监听，有些可以睡死过去。
• 唤醒后的同步开销——重新建立时钟同步、网络关联需要多久，这期间电流可不低。
• 协议本身的 duty cycle 限制——比如 LoRa 的占空比法规限制，NB-IoT 的 eDRX 周期。

我刚开始做 NB-IoT 项目时，以为它和 GPRS 一样耗电，结果发现 eDRX 模式下休眠电流能到 5µA 以下，当时还挺惊讶的。

2.2 各协议休眠功耗横向对比

先看一张我整理的对比表，数据来自主流芯片厂商的 datasheet 和我的实测经验：

协议	典型休眠电流	唤醒建立时间	峰值电流	网络依赖	典型电池寿命（2xAA）
Wi-Fi	10-50 µA (DTIM3)	30-100 ms	200-500 mA	需 AP/路由器	数周~数月
BLE	0.4-1.5 µA	3-6 ms	5-15 mA	需手机/网关	数月~数年
Zigbee	1-3 µA	15-30 ms	25-40 mA	需协调器/网关	数月~2年
LoRa	0.2-1 µA	10-50 ms (CAD)	30-120 mA	需 LoRaWAN 网关	1~5年
NB-IoT	3-5 µA (eDRX)	1-10 s (PSM 唤醒)	200-500 mA	需基站覆盖	数月~2年

2.3 逐个拆解：每个协议的休眠特性

2.3.1 Wi-Fi —— 功耗大户，但生态最成熟

Wi-Fi 的休眠功耗其实不差，尤其是 802.11n 以后的芯片。问题出在它必须和 AP 保持关联，每隔几百毫秒就得醒来听 Beacon 帧。

我记得有个智能插座项目，客户要求用 Wi-Fi，电池供电。我们试了 ESP32 的 Modem-sleep 模式，DTIM=3 时平均电流能压到 80 µA 左右。但用户反馈还是只能撑 3 个月，最后被迫加了超级电容。

• 优势：无需额外网关，直接连路由器，数据速率高。
• 劣势：休眠功耗下限高，不适合年抛型设备。
• 避坑：我曾经以为关闭 Wi-Fi 模块电源就能省电，结果发现重新关联 AP 要 2-3 秒，峰值电流 500mA，反而更费电。

2.3.2 BLE —— 低功耗之王，但连接不可靠

BLE 的休眠功耗是所有协议里最低的之一。nRF52840 在深度睡眠下能到 0.4 µA，而且唤醒只要几毫秒。

但 BLE 有个坑：广播和扫描的 duty cycle 需要仔细调。我做过一个温湿度标签，广播间隔设成 100ms，结果平均电流飙到 30 µA，电池半年就挂了。后来改成 1 秒广播 + 温感触发唤醒，直接撑了 2 年。

• 优势：手机原生支持，开发简单，休眠电流极低。
• 劣势：连接距离短（10-30m），数据吞吐有限，多设备组网复杂。
• 避坑：BLE 的“连接间隔”参数很关键。设太短，设备频繁唤醒；设太长，手机端体验差。我一般建议非实时场景用 100-500ms 连接间隔。

2.3.3 Zigbee —— 网状网省电，但入网麻烦

Zigbee 的休眠节点（End Device）可以睡得很深，父节点会帮它缓存数据。休眠电流通常在 1-3 µA，和 BLE 差不多。

但 Zigbee 的唤醒同步比较耗时。节点醒来后要先发 Data Request 轮询父节点，如果父节点忙，还得重试。我遇到过最极端的情况：一个 Zigbee 门磁，因为父节点信号差，每次唤醒要重试 3-4 次，平均功耗翻了一倍。

• 优势：自组网，多跳传输，适合智能家居全屋覆盖。
• 劣势：需要专用网关，入网流程复杂，OTA 升级困难。
• 避坑：Zigbee 的 poll rate 不要设太快。我习惯用 100ms 轮询间隔，如果对延迟不敏感，可以拉到 500ms。

2.3.4 LoRa —— 远距离低功耗，但速率感人

LoRa 的休眠功耗是所有协议里最低的之一。SX1262 在深度睡眠下只有 0.2 µA，而且支持 CAD（信道活动检测）模式，可以极低功耗监听前导码。

但 LoRa 的数据速率太低了，典型值 0.3-50 kbps。传输一个 50 字节的传感器数据包，可能要占用信道 100-500ms。而且 LoRaWAN 协议有 duty cycle 限制（如 1%），一天最多发几十次。

• 优势：空旷距离 5-15km，穿墙能力强，休眠功耗极低。
• 劣势：数据速率低，延迟高（秒级），需要 LoRaWAN 网关。
• 避坑：LoRa 的扩频因子（SF）直接影响功耗。SF12 比 SF7 传输时间长 4 倍，功耗也翻倍。我一般城市环境用 SF9，郊区用 SF10，尽量不用 SF12。

2.3.5 NB-IoT —— 蜂窝级覆盖，但唤醒代价高

NB-IoT 的休眠模式有 PSM（省电模式）和 eDRX（扩展不连续接收）。PSM 模式下芯片几乎完全断电，休眠电流 3-5 µA。但唤醒后要重新附着网络，耗时 1-10 秒，峰值电流 500mA。

我做过一个智能水表项目，每天上报一次数据。用 PSM 模式，平均电流算下来只有 15 µA，两节 AA 电池撑了 2 年。但如果是每 10 分钟上报一次，PSM 就不划算了，因为唤醒功耗占比太高。

• 优势：运营商基站覆盖，无需自建网关，移动性好。
• 劣势：模块成本高（20-40元），有 SIM 卡费用，唤醒延迟大。
• 避坑：NB-IoT 的 TAU（跟踪区更新）周期要设合理。设太短，频繁唤醒；设太长，基站可能丢失设备。我一般设 24 小时。

2.4 协议选择决策流程

下面这张图是我自己总结的选型逻辑，帮你快速定位：

2.5 我的选型建议

做了这么多年硬件，我总结了几条实用原则：

1. 如果设备离路由器近，且不要求超长续航——选 Wi-Fi。开发快，调试方便，用户不用额外买网关。
2. 如果设备需要手机直连，且功耗敏感——选 BLE。尤其是可穿戴、信标、传感器标签这类产品。
3. 如果设备需要组网覆盖全屋，且节点多——选 Zigbee。智能家居场景首选，但要做好入网引导。
4. 如果设备在户外，且上报频率极低（每天几次）——选 LoRa。电池撑 3-5 年很轻松。
5. 如果设备在户外，且需要运营商级覆盖——选 NB-IoT。但要做好唤醒功耗的预算。