uni-app蓝牙ota升级必须严格分四步执行：连接→握手→分包传输→校验重启；需精确匹配厂商uuid、指令格式及节奏控制，漏一步即失败。
直接说结论：uni-app 蓝牙 OTA 升级不是“调个 API 就行”，而是必须严格按设备协议分阶段走完「连接 → 控制通道握手 → 分包传输 → 校验上报」四步，漏一步就卡死或写入失败。
蓝牙 OTA 前必须确认的硬件协议字段
很多开发者卡在第一步，不是代码问题，是根本没拿到设备方给的准确 UUID 和指令格式。别信“通用服务”这种说法，实际项目中每个厂商都不同。
-
serviceId必须和设备文档一致，常见但不通用的有00001530-0000-1000-8000-00805F9B34FB（Nordic DFU）、15f1e610-a277-43fc-a484-dd39ef8a9100（华为 OTA） -
otaCtrl和otaData两个特征值 UUID 必须分开配置，不能混用；otaCtrl要支持indicate（带应答），otaData通常只支持无应答write - 设备是否要求先发启动指令（如
0x01 0x01）再允许写数据？是否需要每包后等待0x01 0x02确认？这些必须从嵌入式工程师处拿到二进制指令表
uni.createBLEConnection 后不能直接写数据
连接成功回调里立刻调 writeBLECharacteristicValue，90% 情况下会报错 writeBLECharacteristicValue:fail not found service or characteristic。因为服务发现还没完成。
- 必须监听
uni.onBLEConnectionStateChange，等connected === true后，再手动触发uni.getBLEDeviceServices和uni.getBLEDeviceCharacteristics - iOS 下如果
getBLEDeviceCharacteristics返回空，检查是否漏了uni.openBluetoothAdapter的 success 回调，或设备广播未包含对应 service - Android 需确保
manifest.json已声明"android.permission.ACCESS_FINE_LOCATION"，否则服务发现静默失败
固件分包写入必须控制节奏和重试逻辑
蓝牙单次 writeBLECharacteristicValue 实际能写的字节数远小于理论 MTU（通常 ≤ 20 字节），且设备处理速度有限。盲目循环发送会导致丢包、校验失败甚至设备锁死。
- 每次写入后加
await new Promise(r => setTimeout(r, 20))，避免压垮设备接收缓冲区 - 对每包发送做
try/catch，失败时记录当前 offset，支持断点续传（设备端需支持跳过已接收包） - 不要用
ArrayBuffer直接传整个固件文件——先用uni.downloadFile下载到本地临时路径，再用uni.getFileSystemManager().readFile分块读取 - 每包数据前建议加包头（如包序号、CRC16），设备端可据此丢弃乱序包或重复包
升级完成后必须主动触发校验与重启指令
写完所有数据 ≠ 升级完成。设备端收到全部数据后，需要你通过 otaCtrl 发送校验命令（比如 0x03 0x01），再收设备返回的校验结果（如 0x03 0x02 0x00 表示 OK），最后发重启指令（如 0x04 0x01）。
- 校验响应必须用
uni.onBLECharacteristicValueChange监听，且要提前在notify特征值上调用uni.notifyBLECharacteristicValueChange - 设备若返回非预期值（如
0x03 0x02 0xFF），说明 CRC 或长度错误，需回退到上一包重发，而不是继续 - 重启后设备会断连，此时
uni.onBLEConnectionStateChange会触发connected: false，这是正常现象，不要自动重连
最容易被忽略的是：OTA 过程中设备蓝牙连接不能断，但 iOS 后台会冻结 App，所以整个流程必须在前台完成；另外，部分安卓厂商（如 OPPO、vivo）会对持续蓝牙写入限频，得实测调整间隔时间，不能只看文档写的“20ms”。
