90%搜索不到低功耗蓝牙设备源于uni.openbluetoothadapter未真正成功或uni.startbluetoothdevicesdiscovery启动时机/参数/监听注册错误；需检查ios的nsbluetoothalwaysusagedescription配置与android 12+动态权限，确保onbluetoothdevicefound提前注册、传空services及allowduplicateskey:true，并用getbluetoothadapterstate确认适配器就绪。
搜索不到低功耗蓝牙设备，90% 是 uni.openBluetoothAdapter 没真正成功，或 uni.startBluetoothDevicesDiscovery 启动时机/参数/监听注册错了。
uni.openBluetoothAdapter 静默失败是最大拦路虎
它不报错、不弹窗、不回调，尤其在模拟器里必挂（真机才支持），但开发者常误以为“没报错=成功”。iOS 和 Android 失败原因完全不同：
- iOS 必须在
manifest.json的ios节点下配置非空的NSBluetoothAlwaysUsageDescription字符串，且 Xcode 打包时要勾选「Bluetooth Central」后台模式 - Android 12+（API 31+）必须动态申请
scope.bluetoothScan和scope.bluetoothConnect，缺一不可；老版本还需scope.location（因系统把蓝牙扫描归为位置行为） - 失败回调中务必打印
err.errCode：10001表示系统蓝牙未开或定位关闭；10002表示 iOS 描述文案缺失或 Android 权限被拒 - 调用后别急着搜设备，先用
uni.getBluetoothAdapterState()确认available: true且discovering: false，否则适配器没真正就绪
uni.startBluetoothDevicesDiscovery 没回调？监听和参数全错了
启动后无设备返回，不是设备问题，而是扫描逻辑没对上 BLE 协议和平台差异：
-
uni.onBluetoothDeviceFound必须在uni.startBluetoothDevicesDiscovery调用之前注册，且不能用箭头函数（this绑定失效会导致监听丢失） - 传参显式指定
{ services: [], allowDuplicatesKey: true }：空services才能扫到不广播 service UUID 的设备（比如多数自定义硬件）；allowDuplicatesKey: true防止 iOS 漏掉首条广播 - 每次
start前加保险：先uni.stopBluetoothDevicesDiscovery，再setTimeout(300)，避免系统认为上一次扫描还在进行中 - 别依赖
uni.getBluetoothDevices立即查结果——它只返回历史缓存，新设备只通过onBluetoothDeviceFound回调到达
设备广播本身就不稳定，别信“立刻出现”
BLE 广播是异步、间歇、受省电策略影响的，尤其在 iOS 上过滤更严：
- 某些设备只在特定时间窗口广播（比如每 2 秒发一次），所以
duration至少设为 10 秒，别等 1 秒没反应就放弃 - iOS 默认倾向只扫已配对设备，除非你传了
allowDuplicatesKey: true；Android 则可能因省电策略中途停扫 - 真机调试时禁用 HBuilderX 的“USB 连接调试”，改用 Wi-Fi 调试或离线打包，否则蓝牙 API 可能被拦截
- 如果目标设备有公开主 service UUID（如心率表常用
0000180D-0000-1000-8000-00805F9B34FB），务必显式传入services数组，否则默认不匹配
最易被忽略的是：deviceId 必须严格使用 onBluetoothDeviceFound 回调返回的值，大小写敏感，且 iOS 返回的是临时 UUID，不是 MAC 地址——拿错 ID 去连，自然搜得到却连不上、读不了。
