uni-app无法直接获取系统级“已配对”设备列表，仅能通过uni.getconnectedbluetoothdevices获取当前已连接设备，或通过uni.getbluetoothdevices获取本app发现过/连接过的设备缓存（含已断开但曾连接的设备），ios与android均不暴露系统配对枚举能力。
uni-app 无法直接获取系统级“已配对”（paired）设备列表，它只能拿到当前蓝牙模块上下文中“已连接”或“曾发现过”的设备。所谓“配对”是操作系统底层行为，uni-app 的 API 层不暴露 paired 设备枚举能力。
uni.getConnectedBluetoothDevices 只返回当前已连接的设备
这是最接近“已配对”语义但实际限制极多的 API：
- 仅返回
uni.createBLEConnection成功后、且仍处于连接状态的设备（connected: true） - 如果设备已断开，哪怕之前连过十次，也不会出现在这个列表里
- iOS 和 Android 行为一致：断开即消失，不保留历史记录
- 调用前必须确保蓝牙适配器已开启，否则会报错
errCode=10000
示例调用：
uni.getConnectedBluetoothDevices({
success: res => {
console.log('当前已连接设备:', res.devices)
// res.devices 是数组，每个元素含 deviceId、name 等字段
},
fail: err => {
console.error('获取已连接设备失败', err)
// 常见 errCode=10000（未初始化）、10001（蓝牙不可用）
}
})
uni.getBluetoothDevices 返回“发现过 + 曾连接过”的设备缓存
这个 API 才是你真正能拿到“类似已配对”设备的唯一途径，但它本质是 uni-app 内部维护的设备缓存表：
- 包含所有调用过
uni.onBluetoothDeviceFound回调的设备（即扫描到的） - 也包含成功执行过
uni.createBLEConnection的设备（即使当前已断开） - 设备信息中
connected字段可区分当前是否在线 - 注意：该列表不会自动刷新，需在扫描后或连接后主动调用才更新
典型用法：
uni.getBluetoothDevices({
success: res => {
const pairedLikeList = res.devices.filter(d => d.connected || d.deviceId)
console.log('可视为“类配对”设备', pairedLikeList)
}
})
iOS 和 Android 对“已配对”的处理差异极大
这是最容易踩坑的地方：
- iOS：系统级配对（如通过设置 → 蓝牙）对 uni-app 完全不可见；
getBluetoothDevices列表只反映本 App 自己发现/连接过的设备 - Android：部分厂商（如华为、小米）会把系统配对设备透传给 App，但非标准行为；不能依赖，也不稳定
- 两者都**不提供**类似原生
BluetoothAdapter.getBondedDevices()（Android）或retrievePeripheralsWithIdentifiers:（iOS）的能力 - 如果你真需要系统配对列表，必须走 Native.js 或原生插件，uni-app 标准 API 无解
为什么你搜不到“已配对但未连接”的设备？
根本原因不是代码写错，而是 BLE 协议和平台限制：
- 蓝牙“配对” ≠ “广播可见”。配对只是建立密钥，设备不广播时就无法被发现
- 很多设备（尤其传感器）只在开机/唤醒时广播几秒，平时静默——你没在窗口期内扫描，就永远看不到
-
uni.startBluetoothDevicesDiscovery不传services参数时，其实依赖设备广播中的AD Type 0x02 / 0x03（UUID 列表），但大量设备根本不发这个 - 所以别执着于“列出所有已配对设备”，正确做法是：每次使用前主动扫描 + 连接，把常用设备
deviceId存本地缓存，下次直连
最终提醒一句：不要在 onShow 里直接调 getBluetoothDevices，它不保证蓝牙模块已 ready。务必先监听 uni.onBluetoothAdapterStateChange，确认 available: true 且 discovering: false 后再操作，否则大概率返回空数组或报错。
