uni.openBluetoothAdapter失败是连接失败主因，需检查Android权限（BLUETOOTH、BLUETOOTH_ADMIN、ACCESS_FINE_LOCATION）和iOS的NSBluetoothAlwaysUsageDescription配置，再通过errCode判断具体问题。
直接连不上，八成卡在 uni.openBluetoothAdapter 这一步——不是设备没开蓝牙，而是权限、系统状态或平台差异没处理好。
uni.openBluetoothAdapter 失败就别往下走了
绝大多数连接失败，根源都在这一步没过。Android 6.0+ 必须同时声明并动态申请 BLUETOOTH、BLUETOOTH_ADMIN 和 ACCESS_FINE_LOCATION；iOS 则必须在 manifest.json 的 ios 节点里配 NSBluetoothAlwaysUsageDescription，文案不能为空，否则首次调用直接 reject。
- fail 回调里一定要打印
errCode：10001 表示适配器不可用（用户没开蓝牙），10002 是定位未授权（Android）或描述缺失（iOS） - 调用成功后，立刻补一句
uni.getBluetoothAdapterState，确认available: true且discovering: false再启动搜索 - 微信小程序真机调试时，“位置信息”开关藏在微信设置里，不是系统级开关，容易漏掉
startBluetoothDevicesDiscovery 搜索不到设备？先 stop 再 start
这是最隐蔽的坑：你点了“搜索”，代码执行了 uni.startBluetoothDevicesDiscovery，但没反应——很可能上一次搜索没 clean up，系统认为还在进行中，新请求被忽略。UniApp 的蓝牙 API 是单例模型，不允许多个 discovery 并行。
- 每次开始前加保险：先调
uni.stopBluetoothDevicesDiscovery，再setTimeout等 300ms，再 start - 搜索时间别设太长，10 秒足够；超时后必须手动
stop，否则 iOS 持续耗电，Android 可能触发系统限频 -
onBluetoothDeviceFound是唯一可靠监听入口，别依赖getBluetoothDevices立即拿到结果——它返回的是历史缓存，新设备要等回调触发后才入库
连上了却读不到重量？GATT 流程缺一环都不行
BLE 不是“连上就能发”，必须严格走完 GATT 分层：先 createBLEConnection 建链，再 getBLEDeviceServices 找服务（典型是 0x181D），再 getBLEDeviceCharacteristics 找特征值（典型是 0x2A9D），最后才能 notifyBLECharacteristicValueChange 订阅或 writeBLECharacteristicValue 发指令。
- 跳过任一环，
read或notify都会报错 10008（未找到特征值）或 10010（连接已断） - 很多电子秤默认不连续上报，连上后必须先发唤醒指令（如
'RN1'或厂商私有 hex 如'A5A5A5A5'）才能触发通知 - 订阅前务必检查特征值的
properties.notify === true，有些秤把数据放在 write-only 特征值里，得靠写指令触发回传
收到的 ArrayBuffer 怎么解析成公斤数？别硬解十六进制
电子秤数据不是纯数字，而是按厂商协议编码的字节流：可能含 STX(0x02) 开头、CR/LF 结尾；也可能按 BLE 标准体重服务（0x181D）打包，高位在前/低位在前、带符号/无符号、单位换算系数全靠文档或抓包反推。
- 先用
ab2hex或new Uint8Array(res.value)把 ArrayBuffer 转成字节数组，观察稳定时的固定模式 - 常见陷阱：一帧数据被 BLE 分包（两次通知）、或粘包（两帧混在一起），需在 onBLECharacteristicValueChange 里做缓冲和帧头帧尾识别
- 别在页面级写解析逻辑，封装成全局单例，多页面共享连接和解析状态，避免重复连接导致原生层冲突
协议细节和分包处理才是真难点，光连上不代表能拿到可用数据——不同厂家的“标准 BLE 体重服务”实际字段定义、校验方式、唤醒机制几乎都不一样，必须拿真实设备抓包验证。
