“手机断网也能群聊”这件事听起来像是卖手机信号增强器的广告但在物联网通信圈里它确实是一个真实存在且已经工程化的能力。实现它的核心技术叫蓝牙Mesh组网而“多跳传输”正是让消息在没有基站、没有 Wi-Fi 的离线环境里仍然能从一个设备传到几公里外另一个设备的关键机制。这篇文章不打算只给你抄一段官方文档。我会把蓝牙Mesh从“能用”到“在真实项目里能稳定跑起来”这条路上容易踩的坑、容易误解的概念、以及开源生态里真正值得投入的方案讲清楚。如果你正在做离线通信、应急指挥、仓储物流、智能家居或者户外探险类项目这篇文章会帮你省下不少调研时间。1. 先搞清楚手机断网群聊难点到底在哪我们先把需求拆开。所谓“手机断网也能群聊”本质上要解决三件事没有基站、没有 Wi-Fi 时设备之间怎么建立连接。一个设备发送的消息怎么让距离更远的设备也能收到。多个设备组成的通信网络怎么在没有中心服务器的情况下稳定运行。第一件事蓝牙就能解决。但传统的蓝牙是一对一连接就像两个人打电话旁边的人听不到。第二件事就需要一种网络机制。而第三件事是蓝牙Mesh最核心的价值。很多人第一次接触蓝牙Mesh会误以为它就是把蓝牙信号放大或者像 Wi-Fi 中继一样一层一层转发。这个理解方向是对的但实现机制完全不同。蓝牙Mesh不是简单的中继桥接它采用的是**受管理洪泛Managed Flooding**机制消息发送后网络中的中继节点会按照一定的规则把消息广播出去其他节点收到后继续广播直到消息的生存时间TTL耗尽。换句话说蓝牙Mesh更像是一个“消息接力赛”每个节点都是接力手而接力棒是带有目的地址的消息包。这个机制的好处是网络不需要中心节点任何一个设备掉线其他设备仍然可以继续通信坏处是如果配置不当消息会在网络里反复转发造成“广播风暴”。所以真正让“手机断网群聊”成为现实的不是蓝牙技术本身而是蓝牙Mesh这套组网和消息分发机制。理解了这个前提你就能明白为什么现在越来越多的开源项目和硬件方案都在围绕蓝牙Mesh做文章。2. 蓝牙Mesh核心原理一次握手多跳转发2.1 从一个比喻开始你可以把蓝牙Mesh网络想象成一个没有微信群聊的大学宿舍楼。你住在一楼你的朋友住在五楼但你们之间没有手机信号。你想传一句话给他怎么办你只需要把这句话写在纸条上交给二楼的室友二楼的室友再传给三楼这样一层一层传上去。这里的三楼、四楼、五楼就是蓝牙Mesh网络里的“节点”。而每层楼之间传纸条就是“多跳传输”。关键点在于你的朋友不需要直接在你旁边只要你俩之间有一连串节点愿意帮忙转发消息就能送达。这个比喻还说明了另一个重要特性不需要中心服务器。宿舍楼里没有任何一个“总管理员”来调度传纸条每层楼的人只需要把纸条传出去大家自然配合完成了通信。2.2 蓝牙Mesh网络里的核心角色在蓝牙Mesh网络中节点分为几种角色它们的分工必须搞清楚角色作用类比Node节点网络中的基本单元可以发送和接收消息宿舍楼里的每个房间Relay Node中继节点收到消息后继续转发实现多跳愿意帮忙传纸条的宿舍Proxy Node代理节点让不支持Mesh的普通蓝牙设备接入网络一楼传达室能帮你和楼上沟通Provisioner配置者负责把新设备加入网络、分配地址和密钥宿舍管理员这里面最容易忽略的是Relay Node。在一个蓝牙Mesh网络里并不是所有节点都必须开启中继功能。如果每个节点都开启中继网络会非常拥挤。所以在实际项目里通常只让固定位置、供电充足的设备开启中继比如墙插式智能灯泡、网关等。2.3 TTL消息的“生命倒计时”多跳传输不是无限转发的。每条消息在发出时都带有一个 TTL 字段Time To Live表示这个条消息最多还能被转发多少次。每经过一个中继节点TTL 减 1当 TTL 为 0 时消息被丢弃。TTL 的设计非常关键。它既保证了消息能通过多跳到达远处又防止了消息在网络里无限循环。你可以把它理解为快递包裹上的“加急期限”过期后快递就不再转手了。2.4 发布/订阅不是所有消息都要发给所有人蓝牙Mesh的消息传输并不是把所有数据广播给网络里的每一个节点而是采用发布/订阅模型。每个节点可以订阅某些主题在蓝牙Mesh里称为 Group Address 或 Label UUID也可以向某个主题发布消息。举个例子你家里有 10 个智能灯泡它们都订阅了“客厅灯”这个主题。当你按下客厅的开关开关向“客厅灯”发布了一条开灯消息。这 10 个灯泡会收到消息并执行开灯动作而卧室的灯泡因为没订阅这个主题不会收到消息。这个机制对群聊场景同样适用。你可以创建一个“山地救援队”主题所有队员的手机或对讲设备订阅这个主题任何一个人发消息整个救援队都能收到。发布/订阅机制让消息在Mesh网络里得到精准分发而不是无脑全广播。3. 为什么是蓝牙Mesh与 Wi-Fi、经典蓝牙、LoRa 的对比很多人会问既然要离线通信为什么不用 Wi-Fi 直连、经典蓝牙或者 LoRa这个问题的答案其实就藏在组网方式里。3.1 与经典蓝牙对比经典蓝牙BR/EDR和低功耗蓝牙BLE都是一对一连接模型。一个主设备最多同时连接 7 个从设备经典蓝牙BLE 也基本是星型拓扑。这种模式做“群聊”非常吃力因为你要维护大量的连接而且设备与设备之间不能直接通信必须通过主设备转发。蓝牙Mesh改变了这个局面。它让设备之间形成网状拓扑消息可以通过多跳从一个设备传到另一个设备不再依赖中心节点。3.2 与 Wi-Fi 对比Wi-Fi 的最大问题是依赖路由器。没有路由器两个 Wi-Fi 设备之间虽然可以走 Wi-Fi Direct但那也是一对一的连接而且建立连接的过程非常繁琐。蓝牙Mesh则天然就是去中心化的不需要任何基础设施。从功耗角度看BLE 的功耗远低于 Wi-Fi。一个纽扣电池供电的蓝牙Mesh节点可以运行数月甚至数年而 Wi-Fi 设备通常需要持续供电。在应急通信、传感器网络等场景里功耗往往是决定性因素。3.3 与 LoRa 对比LoRa 的特点是用极低的速率换取极远的通信距离单跳可以做到几公里甚至十几公里。但它的问题在于速率太低传个小文本消息还可以传语音、图片就非常吃力。蓝牙Mesh虽然单跳距离只有几十米但通过多跳理论上可以覆盖任意大的区域而且速率比 LoRa 高得多能够承载更丰富的消息类型。3.4 一张表看明白怎么选对比维度蓝牙Mesh经典蓝牙Wi-FiLoRa组网方式多跳网状拓扑一对一/星型依赖AP/路由器星型/点对点是否需要中心节点不需要需要主设备需要路由器需要网关单跳通信距离数十米数十米数十米至百米数公里多跳支持原生支持不支持需要自组网协议有限支持功耗低中等高极低传输速率数十kbps至1Mbps1-3Mbps数十Mbps以上0.3-50kbps典型应用智能家居、离线群聊、应急通信音箱、耳机视频、网页远程传感器从这张表可以清晰看到蓝牙Mesh擅长的是“中等距离、低功耗、去中心化、消息精准分发”的场景。它不是一个万能方案但在“手机断网还能群聊”这个具体需求上它几乎是开源社区里最实用的选择。4. 手机端为什么难做 Mesh 节点协议栈现实与 Proxy 方案聊到这里细心的人会提出一个灵魂问题既然蓝牙Mesh这么好那我手里的手机能不能直接当成一个Mesh节点和其他手机组网群聊答案没那么简单。操作系统对蓝牙协议栈的限制决定了手机很难直接成为标准Mesh节点。4.1 iOS 的限制iOS 的 CoreBluetooth 框架对 BLE 的使用有严格限制。App 只能以 Central中心设备或 Peripheral外围设备的角色工作无法完全控制 Mesh 协议栈底层的广播和扫描调度。简单说iOS 并没有向开发者开放底层 Mesh 协议栈你只能在系统层之上通过 Mesh Proxy 协议间接接入 Mesh 网络。4.2 Android 的限制Android 虽然在较新版本里加入了 Mesh 协议栈的支持通过 BluetoothLeMesh 相关 API但实际使用中碎片化问题非常严重。不同厂商的手机对 BLE 广播、扫描、多连接的支持差异很大开发一个能在多数 Android 手机上稳定运行的原生 Mesh 节点 App工作量远远大于在嵌入式设备上实现 Mesh。4.3 现实方案手机 Proxy 网关既然手机本身不适合做 Mesh 节点那么“手机断网群聊”的落地模式通常是这样的一套蓝牙Mesh网络由若干硬件节点组成比如 ESP32 开发板、智能网关、对讲机模块。其中一个硬件节点开启Proxy 功能让普通手机通过标准 GATT 连接接入这个节点。手机 App 通过 Mesh Proxy Protocol 将消息发送给代理节点代理节点把消息翻译成 Mesh 消息再通过多跳传输发给网络里的其他节点。这个方案的优点非常明显手机端不需要实现完整的 Mesh 协议栈只需要实现简单的 Proxy Client 逻辑而把复杂的组网、路由、中继交给嵌入式节点去处理。在工程上这种“手机App 嵌入式Mesh网关”的架构才是真正可行且可维护的。理解了这一点你就知道为什么真正值得研究的开源项目通常集中在嵌入式设备端而不是手机 App 端。5. 开源方案怎么选三个主流框架横向对比5.1 ESP-BLE-MESH最适合入门到实战的路径乐鑫Espressif官方提供的 ESP-BLE-MESH 是基于 ESP-IDF 开发框架的蓝牙Mesh协议栈实现硬件平台是 ESP32 系列芯片。ESP-BLE-MESH 的优势在于文档齐全。乐鑫在官方文档上对蓝牙Mesh的讲解非常详细从基础概念到 API 参考都覆盖了适合初学者系统学习。例程丰富。ESP-IDF 自带 ble_mesh 相关示例包括 onoff server、onoff client、lighting 等你可以直接基于示例开发。芯片成本低。ESP32 系列芯片在淘宝、立创商城等渠道都能方便买到开发板价格也很亲民。社区活跃。ESP32 是全球开发者量最大的物联网芯片之一遇到问题更容易找到解决方案。ESP-BLE-MESH 的问题在于它对较大规模网络的性能优化比较一般如果你要组一个几百个节点的网络可能需要做很多调优工作。但从学习到项目验证它是最顺畅的路径。5.2 Zephyr更标准、更复杂Zephyr 是一个开源实时操作系统它内置了完整的 BLE Mesh 协议栈zephyr/bluetooth/mesh。Zephyr 支持的硬件平台非常多包括 Nordic nRF52 系列、ESP32 等。Zephyr 的优势是协议栈实现比较标准跟蓝牙SIG规范贴合度高适合对规范理解比较深入、或者需要跨多个芯片平台做产品化的团队。但它的学习曲线比 ESP-IDF 陡峭不少Kconfig 构建系统、设备树Device Tree这些概念对新手有门槛。5.3 nRF Connect SDKNordic 生态的硬核玩家Nordic 的 nRF5 SDK 和 nRF Connect SDKNCS也提供了完善的蓝牙Mesh支持。Nordic 芯片在性能和协议栈成熟度上表现优秀但芯片成本和开发门槛都更高。nRF Connect SDK 还提供了非常专业的手机端调试工具 nRF Mesh对调试 Mesh 网络非常有帮助。5.4 怎么选框架适合人群学习难度硬件成本社区活跃度ESP-BLE-MESH入门新手、快速原型验证低低极高Zephyr追求标准、需要跨平台中高中高nRF Connect SDK产品化、专业场景高高高我的建议是如果你第一次接触蓝牙Mesh不要犹豫直接用ESP32 ESP-IDF ESP-BLE-MESH。先把官方示例跑起来理解组网流程和消息转发的日志输出再逐步添加自己的业务逻辑。等你对 Mesh 有了手感再去看 Zephyr 或 nRF 的源码会事半功倍。6. 环境准备与最小工程ESP32 ESP-IDF6.1 硬件准备至少 3 块 ESP32 开发板推荐 ESP32-DevKitC 或 NodeMCU-32SUSB 数据线若干可选5V 充电宝或 USB 电源为什么推荐至少 3 块因为你需要验证“A 设备发送消息 → B 设备中继转发 → C 设备收到消息”的完整多跳链路。两块的验证价值太有限。6.2 软件环境ESP-IDF 的安装方式与官方建议保持一致即可。推荐使用 ESP-IDF 的最新稳定版本因为蓝牙Mesh的 API 在持续演进。如果你需要更稳妥的版本可以参考官方 release 页面进行选择。本文不锁定具体版本因为不同版本之间 API 略有差异但整体思路是通用的。安装完成 ESP-IDF 后你可以通过下面的命令验证环境是否正常idf.py --version如果输出类似 “ESP-IDF v5.x” 的版本信息说明环境已经就绪。6.3 获取示例工程ESP-IDF 官方仓库中带有现成的蓝牙Mesh示例。以 ESP-IDF v5.x 为例示例目录位于$IDF_PATH/examples/bluetooth/esp_ble_mesh/其中wifi_coexist、onoff_server、onoff_client等目录都是很好的学习起点。我们先用onoff_server作为基础因为它的逻辑最简单节点可以接收开/关命令然后执行相应动作。理解了 onoff 模型的收发流程再扩展到群聊文本消息就非常自然了。7. 核心流程与示例代码从配网到消息转发7.1 整体流程拆解一个完整的蓝牙Mesh消息发送流程由四个阶段构成Provisioning入网配置用一个 Provisioner 设备通常是一个支持 Mesh 配网功能的手机 App 或开发板把新的节点加入网络分配网络地址和密钥。订阅与发布设置节点通过 Composition Data 获取对方支持哪些模型Model然后配置节点的订阅地址和发布地址。消息收发业务代码调用模型Model的 publish 接口把消息发布到指定地址对端节点在收到消息后通过回调函数处理消息。多跳转发中继节点根据 TTL 和订阅关系决定是否转发消息。7.2 最小工程初始化下面是一个基于 ESP-IDF 的蓝牙Mesh初始化示意代码。这里要特别强调不同版本的 ESP-IDF API 存在差异下面的代码用于展示整体思路你在实际使用时请以当前版本的官方示例为准。// 文件路径main/main.c #include stdio.h #include esp_log.h #include esp_ble_mesh_defs.h #include esp_ble_mesh_networking_api.h static const char *TAG mesh_node; // 蓝牙Mesh节点的初始化入口 static void mesh_init_complete(void) { ESP_LOGI(TAG, Mesh node init complete, waiting for provisioning...); } void app_main(void) { esp_ble_mesh_cfg_t cfg { .mesh_init_complete mesh_init_complete, }; esp_err_t err esp_ble_mesh_init(cfg); if (err ! ESP_OK) { ESP_LOGE(TAG, Failed to init mesh: %s, esp_err_to_name(err)); return; } }这只是一个启动骨架。要让节点真正入网并发送消息还需要配置 Provisioning 相关的参数包括 UUID、认证方式、网络密钥等。这些内容在 ESP-IDF 的onoff_server示例中都有完整实现建议先把官方示例原封不动地编译烧录确认整条链路可以跑通。7.3 订阅与发布逻辑让消息被“精准投递”在onoff_server示例中节点默认会订阅一个组地址0xC000并且支持开关状态的上报。在实际项目中你要做的是扩展一个自定义的 Vendor Model用它来承载文本消息。一个典型的 Vendor Model 回调逻辑如下示意代码// 文件路径main/vendor_model.c #include esp_ble_mesh_vendor_model_api.h #define CID_ESP 0x02E5 // Espressif 的 Company ID #define MODEL_ID_MSG 0x0001 // 收到对端发来的消息时这个回调会被触发 static void vendor_model_msg_cb(esp_ble_mesh_model_t *model, esp_ble_mesh_msg_ctx_t *ctx, esp_ble_mesh_model_msg_t *msg) { ESP_LOGI(TAG, Received message, opcode0x%04x, length%d, msg-opcode, msg-length); ESP_LOGI(TAG, Payload: %.*s, msg-length, (char *)msg-data); }这里最需要理解的是Model模型的概念。在蓝牙Mesh里Model 定义了一组消息和对应的行为你可以把它理解成服务器上的一个接口。官方定义了 Generic OnOff、Generic Level、Light Lightness 等标准 Model而 Vendor Model 是厂商自定义扩展的 Model可以用来传输任意业务数据。群聊文本消息就是用 Vendor Model 的 Send/Receive 消息来实现的。7.4 发布消息向指定地址发送群聊内容当用户在群聊界面输入一段文字后App 或设备端需要把这段文字打包成消息发布到目标地址。示意代码如下// 文件路径main/publish_msg.c #include esp_ble_mesh_vendor_model_api.h // 向群组地址发送一条文本消息 static void send_group_message(esp_ble_mesh_model_t *model, char *text) { esp_ble_mesh_msg_ctx_t ctx {0}; ctx.addr 0xC000; // 群组地址 ctx.model model; esp_ble_mesh_model_op_t op { .opcode 0x01, // 自定义 opcode .min_len 1, .max_len 300, }; esp_ble_mesh_vendor_model_send(model, ctx, op, strlen(text), text); }这里有几个关键点addr设为0xC000表示这是一个组播地址。网络中订阅了该地址的所有节点都会收到消息。opcode是自定义的用于标识这个消息类型。官方规定的 Vendor Model opcode 范围以0xC0开头具体分配规则参考蓝牙Mesh规范。max_len表示单条消息的最大长度受限于底层 MTU 和辅助数据不要设置过大。7.5 编译与烧录在 ESP-IDF 环境中编译烧录的命令非常简单idf.py build idf.py -p /dev/ttyUSB0 flash monitor其中/dev/ttyUSB0需要替换为你自己电脑上识别到的串口设备。例如 Windows 下可能是COM3、COM4等。烧录完成后设备会打印类似以下日志I (123) mesh_node: Mesh node init complete, waiting for provisioning...此时设备已经处于被配网状态说明你的工程已经跑起来了。8. 运行结果与效果验证日志里藏着一切8.1 怎么判断消息真的发送成功了蓝牙Mesh的日志输出比普通 BLE 透传要复杂一些但有几条关键日志可以帮助你判断消息流通链路。以官方onoff_server为例当手机 App比如 nRF Mesh 或 espBleMesh App给节点发送开关命令后设备日志会出现类似这样的输出I (5231) example_onoff_server: Received message: opcode0x8201, from 0x0001 I (5231) example_onoff_server: OnOff state 1这里opcode0x8201是 Generic OnOff Set 消息的操作码from 0x0001表示消息的源地址。如果你的设备能够打印这段日志说明消息已经成功到达节点。对于你自己的 Vendor Model 文本消息你在回调函数里打印了收到的数据所以启动后立刻就能看到接收内容。验证时不要只盯着一块板子。建议把三块板子分别放在不同房间相距五米以上然后从 A 板发送消息观察 B、C 板是否能收到。如果 C 板也能收到说明 B 板的中继转发能力已经生效。8.2 一个简单的多跳验证方案假设你手上有三块 ESP32节点A电源供电开启中继功能作为消息源。节点B电源供电开启中继功能放在A和C之间。节点C电源供电关闭中继功能作为消息接收端。先在手机上用 Provisioner 把所有节点加入同一个网络并给所有节点订阅同一个组地址0xC000。然后让 A 发送一条消息观察 C 是否收到。如果 C 收到了你可以通过打印节点B的日志确认B收到了来自A的消息并进行了转发。实际日志中中继行为的包络日志和业务消息日志是分开打印的要注意区分。8.3 如果消息没到先看这几个地方问题现象排查方向节点无法被配网检查节点是否处于 Provisioning 等待状态检查手机 App 与节点的距离是否过远节点已入网但收不到消息检查订阅地址和发布地址是否一致是否开启了中继功能消息只能到下一跳无法多跳检查中继节点的 TTL、中继开关是否开启消息偶尔丢失检查广播冲突降低消息频率调整网络重发参数9. 常见问题与排查方法这一节专门整理我在实际项目中遇到频率最高的几个问题给你一份可以直接照着查的清单。问题现象可能原因排查方式解决方案esp_ble_mesh_init返回错误ESP-IDF 版本与示例代码不匹配查看编译日志中的具体错误码参照当前版本 API 文档修改代码配网时手机 App 扫描不到节点节点未进入可配网状态或距离太远查看串口日志中是否等待配网重新烧录并确认日志缩短手机与节点距离节点入网成功但无法收发消息订阅/发布地址配置错误检查 Composition Data 和 AppKey 配置重新配置节点的订阅地址多跳消息无法到达远端节点中继节点未开启 Relay 功能检查节点的 Relay 状态通过配置消息开启 Relay消息延迟很高TTL 设置过大转发过于频繁降低 TTL根据网络规模合理设置 TTL电池设备很快没电节点持续开启中继和扫描检查低功耗模式配置电池设备关闭 Relay降低广播频率这里要特别提醒一个容易被忽略的问题认证方式。蓝牙Mesh配网时Provisioner 和节点之间需要完成认证。常见的认证方式有 Output OOB、Input OOB 和 Static OOB。如果节点打印了static oob相关日志而你手机 App 里没有配置相同的静态密钥配网会一直失败。建议开发时先使用无 OOB 或固定 Static OOB跑通流程后再换成更安全的认证方式。10. 最佳实践与工程建议10.1 网络密钥管理不要把生产密钥写死在代码里蓝牙Mesh网络的安全性依赖于网络密钥NetKey和应用密钥AppKey。真实项目中密钥不应该硬编码在固件里。建议的做法是每个产品使用独立的 NetKey避免一个设备被破解导致整个网络失控。AppKey 按业务功能划分比如“门锁管理”和“灯光控制”使用不同的 AppKey。生产环境在下线时通过安全烧录工具写入密钥而不是在源码里维护。10.2 中继节点别铺太满中继节点是蓝牙Mesh转发消息的关键但不是越多越好。在一个房间有 10 个 ESP32 节点的情况下如果全部开启 Relay广播冲突会非常严重。建议固定供电的节点开启 Relay电池供电节点关闭 Relay仅在需要时临时开启。10.3 注意消息风暴蓝牙Mesh本身能承载的并发消息有限。如果多个节点同时发送消息网络会拥塞。在设计群聊应用时建议加一个简单的发送队列限制同一设备每秒最多发送 3-5 条消息。如果需要传输大文件不要直接塞进 Mesh 消息而是通过 Mesh 网络协商一个临时通道或采用分段重传机制。10.4 日志与调试调试蓝牙Mesh时建议利用 ESP-IDF 的日志分级功能将蓝牙协议栈日志调到VERBOSE级别可以在串口监视器中看到详细的协议栈状态idf.py menuconfig在Component config → Bluetooth → Bluedroid Options → BT_LOG中调整日志级别。调试完记得改回生产级别的日志避免影响性能。10.5 生产环境的 OTA 更新ESP32 支持 OTA 升级。在蓝牙Mesh场景里做 OTA需要注意 Mesh 消息不支持大包传输固件升级包需要通过分包发送并在接收端做组装和校验。这是另一个复杂的工程模块建议在功能稳定后再考虑。11. 总结与后续学习方向回到最初的问题手机断网能不能群聊从技术实现的角度看完全能但它的价值不在于“替代微信”而在于“在没有基站、没有 Wi-Fi 的环境里建立一条可靠去中心化的消息通道”。蓝牙Mesh组网和多跳传输正是这条通道的地基。本文真正想让你带走的东西有三点第一蓝牙Mesh的核心不是“蓝牙”而是“Mesh”。它的多跳转发、发布订阅、去中心化特性决定了它适合离线通信、应急指挥、智能家居设备联动等场景。第二手机端做不了完整的Mesh节点这不是芯片算力问题而是操作系统协议栈的限制。工程上可行的架构是“手机 App 嵌入式 Mesh 网关如 ESP32”。第三开源生态里ESP32 ESP-IDF ESP-BLE-MESH 是入门成本最低、社区最活跃的路线。先用官方示例跑通再做自定义 Vendor Model最后再考虑网络优化和安全加固。如果你看完这篇文章准备动手可以按这个顺序推进准备 3 块 ESP32 开发板安装好 ESP-IDF。编译烧录官方onoff_server示例用手机 App 完成配网。修改示例加入自己的 Vendor Model实现文本消息的发送和接收。调整 TTL 和中继配置验证三节点多跳链路。蓝牙Mesh还有一个经常被低估的应用方向蓝牙Mesh与手机定位的结合。通过测量多个 Mesh 节点之间的信号强度可以估计设备之间的相对位置。这对于室内仓储、人员定位等场景非常有价值。如果你在做物联网相关项目把蓝牙Mesh作为底层通信链路会是一个非常扎实的起点。建议先把本文配网到消息转发这条主链完全吃透再根据业务需求扩展。