必须先调用 uni.notifyBLECharacteristicValueChange 启用通知且等待 success 回调，再注册 uni.onBLECharacteristicValueChange 监听，否则收不到数据；启用前须确认 characteristic.properties.notify 为 true，避免错误码 10008；监听前应清除旧监听，数据为 ArrayBuffer 需转 Uint8Array 处理；安卓需及时设置 MTU 至 128 并注意系统限频。
必须先调用 uni.notifyBLECharacteristicValueChange 启用通知，再监听 uni.onBLECharacteristicValueChange，否则收不到任何数据。
启用 Notify 前必须确认特征值支持 notify 属性
很多报错 notifyBLECharacteristicValueChange:fail no descriptor（错误码 10008）根本原因不是代码写错，而是选错了 characteristicId——该特征值的 properties.notify 为 false。
- 务必在调用
uni.getBLEDeviceCharacteristics后检查返回的每个特征值的properties字段，只对notify: true的特征值调用启用通知 - 不能凭 UUID 猜测或硬编码；同一设备不同固件版本可能开放不同特征值
- 某些设备存在多个同名 UUID 特征值（如资料中提到的两个
4348411D-444C-5020-4E49-52204E616E6F），需结合properties和位置索引判断 - 微信小程序里可能“侥幸”通过，但 uni-app 多端运行时会严格校验 descriptor，跨端失败率极高
监听回调必须在启用通知后注册，且不能重复绑定
uni.onBLECharacteristicValueChange 是全局事件监听器，一旦注册就会持续接收所有已启用 notify 的特征值变化。若未清理旧监听，容易导致「消息轰炸」或回调执行多次。
- 建议在连接设备后、启用 notify 前，先调用
uni.offBLECharacteristicValueChange()清除可能残留的监听 - 监听回调函数应定义在组件 data 或 setup 中，避免闭包引用过期的
this或ref - 不要在循环中反复调用
onBLECharacteristicValueChange；一次注册即可，它本身不绑定具体特征值 - 监听到的数据是
ArrayBuffer，需用new Uint8Array(res.value)转为字节数组再处理，直接String.fromCharCode或TextDecoder解码前要确认设备发送的是 UTF-8 文本
安卓端需注意 MTU 设置与通知延迟
安卓系统默认 MTU 为 23 字节，若设备单次推送数据超过此长度（比如传感器打包了 16 字节原始值 + 时间戳），会被截断或丢弃，表现为「偶尔收不到」「数据错位」。
- 连接成功后尽快调用
uni.setBLEMTU({ deviceId, mtu: 128 })（推荐 128，兼容性好） - 该 API 仅在安卓 5.1+ 有效，iOS 不支持也不需要；调用时机必须在
uni.createBLEConnection成功之后 - 部分安卓机型（尤其厂商定制 ROM）对 notify 频率有限制，连续高频推送（如 >20Hz）可能被系统合并或降频，需硬件配合做数据缓存+批量上报
最常被忽略的一点：uni.notifyBLECharacteristicValueChange 的 state: true 调用只是「请求开启」，并不保证立刻生效；必须等 success 回调返回后再注册监听，否则前几包数据大概率丢失。这个时序问题在调试阶段极难复现，上线后才暴露为「偶发首包丢失」。
