蓝牙、Wi-Fi、Zigbee、LoRa、NB-IoT 的适用场景

蓝牙、Wi-Fi、Zigbee、LoRa、NB-IoT 常常一起出现在方案初期。它们都能让设备联网，可项目后面顺不顺，更多取决于设备安装位置、供电条件、数据频率、维护方式和上线范围。协议选对了，硬件、App 和云端之间会少很多拉扯；协议只跟着热门词走，后面很容易在续航、覆盖和联调上补课。

企业项目很少能靠一张参数表定案。传输距离、组网方式、功耗预算、运营商资源、云端接入和 App 交互会一起影响判断。已经进入立项阶段的项目，可以先对照 MQTT物联网系统开发、IoT定制开发服务 和 农业种植环境监测平台案例，判断当前项目更接近设备上云、近场控制，还是长距离低频采集。

现场条件先落地

协议选择的第一步，是把设备准备放在哪里说清楚。室内短距离控制、园区巡检、农田采集、工厂仓库、城市分布式设备，现场差异很大。有没有稳定电源，有没有现成局域网，设备是否常在线，数据按秒上报还是一天几次，这些条件一明确，候选范围就会收窄。

现场网络稳定、设备不靠电池长期待机时，Wi-Fi 往往容易进入主选。它的优势很直接，带宽够，开发资源多，调试也直观。代价也很直接，覆盖半径和功耗都不轻，设备分散得太开，网络维护不会轻松。

蓝牙适合近距离交互。它常见于设备配网、本地控制、穿戴设备连接和小范围数据同步。若项目重点是手机靠近设备后的控制体验，或者设备本身在意低功耗，蓝牙会很自然。若现场要求跨楼层、跨园区长期回传数据，蓝牙就不适合作为唯一主链路。相关项目可以继续看 蓝牙APP开发 和 蓝牙+4G App开发。

协议各有边界

Zigbee 面向多节点组网更常见。智能家居、楼宇控制、传感器密集部署这类项目，经常会把它纳入主选。它的价值不在单个设备速度多快，重点在节点多起来以后，组网和低功耗仍能维持相对稳定的状态。项目如果准备接很多开关、传感器和执行器，Zigbee 往往比 Wi-Fi 更省心，也比单纯靠蓝牙更适合撑起设备网络。

LoRa 常见于距离更长、数据量不大、上报频率不高的场景。农业监测、园区环境采集、分散式设备告警，都属于它比较适合出现的地方。它的优势在覆盖和功耗，代价是吞吐量和实时性不能按高频控制来期待。周期性采样、远距离回传、低功耗部署，LoRa 很有价值；连续视频、频繁控制和复杂交互就不该压在它身上。

NB-IoT 适合把设备直接接入运营商网络。分布零散、布线困难、需要广域覆盖的设备，常会考虑这类方案。水务表计、抄表终端、城市级分布式感知设备，都是典型场景。它的便利来自网络现成，同时也要把资费、运营商覆盖、模组能力和消息频率一起算进去。若设备要高频双向控制，或者现场对时延更敏感，就要谨慎。

很多项目最后会把链路分层。近端用蓝牙或 Zigbee，远端回传走 Wi-Fi、LoRa、4G 或 NB-IoT，这并不奇怪。关键在于职责要写清楚，App、网关、云端分别接哪一段，异常发生后由哪一端记录和提示。若设备还涉及控制器、Modbus 或工业网关，可以继续看 Modbus App开发 与 工业物联网平台开发。

协议要和系统一起定

协议选型进入交付后，会连着硬件、云端和 App 一起动。设备鉴权、消息上行频率、离线补发、现场升级、网关转换、日志留存，都不能等开发中途再补。前面图省事，后面常会变成硬件改一轮、平台补一轮、App 再跟着改一轮。

较稳的做法，是把业务目标和通信链路放在同一张项目说明里。近场控制项目，先把蓝牙交互和配网流程想透；多节点组网项目，先看 Zigbee 网络结构和维护方式；长距离低功耗项目，把 LoRa 或 NB-IoT 的覆盖、资费和上线节奏算进去。还在前期评估时，可以通过 联系我们 提交设备安装环境、供电方式、数据频率和目标上线范围，也可以先看 常见问题 里的周期、预算和私有化说明。