uni-app 官方蓝牙 API 不支持蓝牙 Mesh，因其仅封装标准 BLE（GATT）能力，缺失 Mesh 协议栈、配网、消息中继等核心功能；可行方案为开发原生插件或采用外部网关中转。
uni-app本身不支持蓝牙Mesh
直接说结论：uni-app 的官方蓝牙 API（如 uni.openBluetoothAdapter、uni.createBLEConnection）只封装了标准 BLE（GATT）能力，**完全不包含 Mesh 协议栈、消息中继、节点配网、虚拟地址管理等核心功能**。所谓“uni-app 实现蓝牙Mesh”，本质上是伪命题——它连 provisioning（配网）、mesh message 解析、friendship 或 relay 状态控制这些基础操作都无法触发。
为什么不能靠uni-app原生API做Mesh
原因很实在：
-
uni.startBluetoothDevicesDiscovery只能扫到广播包（advertising data），但 Mesh 设备默认使用「非连接态广播」（unprovisioned device beacon），且不响应传统 GATT 连接请求；uni-app 没有暴露底层 HCI 或 Mesh Beacon 解析接口 -
uni.getConnectedBluetoothDevices返回的是已建立 GATT 连接的设备列表，而 Mesh 节点之间不依赖持续连接，而是靠中继转发，这个模型 uni-app 根本没映射 - 所有 Mesh 操作（如发送配置消息、绑定 AppKey、设置发布地址）都需要构造符合 SIG Mesh Profile v1.0.1 的 PDU，并加密签名，uni-app 的
uni.writeBLECharacteristicValue无法满足字节级控制和加密要求 - iOS 平台限制更死：CoreBluetooth 不开放 Mesh 相关 API，即使你绕过 uni-app 自己写原生插件，App Store 也大概率拒审
可行路径只有两条：原生插件 or 外部网关
如果你真要落地 Mesh 控制，必须跳出 uni-app 蓝牙 API 层：
-
方案一：开发原生插件：在 Android 上基于
no.nordicsemi.android:mesh（v3.2.0+）封装插件，在 iOS 上用CoreBluetooth+ 第三方 Mesh SDK（如 Silvair 或 Blue Gecko SDK）桥接。插件需暴露provisionDevice、sendMessageToAddress、subscribeGroupAddress等方法，uni-app 仅负责 UI 和调用。注意：Android 需动态申请BLUETOOTH_SCAN和ACCESS_FINE_LOCATION，iOS 需NSBluetoothAlwaysUsageDescription - 方案二：用网关中转：让 Mesh 设备接入一个物理网关（如 ESP32-Mesh + MQTT），uni-app 通过 WebSocket 或 HTTP 调用网关 API 控制节点。这种方式放弃直连，但规避了所有平台限制，适合展厅、酒店等固定部署场景
别信“uni-app + JS 库实现 Mesh”的说法——那些库（比如 ble-mesh）只是模拟器或解析工具，没法驱动真实硬件。
最容易被忽略的坑：iOS 上根本跑不通
哪怕你写了完美 Android 插件，iOS 仍是死结：
- 苹果禁止 App 主动扫描未配网 Mesh Beacon（类型 0x29）
- 无法获取 Mesh 设备的 Provisioning OOB 数据（如 QR Code 中的 Static OOB）
- 没有权限调用
CBPeripheralManager发送 Mesh Provisioning PDUs
所以，如果你的项目必须上架 App Store，Mesh 控制只能走网关模式，或者接受 iOS 端降级为“仅监控状态”，控制权交给 Web 后台或独立 iOS App。
