频繁断开后立即重试createBLEConnection大概率失败，主因是系统连接句柄泄漏与状态未清理；必须在每次调用前先执行closeBLEConnection并等待回调，再加退避延迟和设备状态校验。
频繁断开后 uni.createBLEConnection 立即重试大概率失败，不是代码写错了，是系统底层连接句柄泄漏+状态未清理导致的资源耗尽。关键不在“怎么连”，而在“连之前有没有真正断干净”。
createBLEConnection 失败前必须先 closeBLEConnection
很多开发者以为 uni.closeBLEConnection 只是可选清理步骤，其实它是强制前置条件。Android（尤其华为、小米）在多次调用 createBLEConnection 后不显式关闭，会累积无效连接句柄，最终触发系统级限流——表现为超时时间从 30s 自动缩短到 5–7s，且所有后续连接均返回 createBLEConnection:fail operate time out。
- 每次调用
createBLEConnection前，务必先对同一deviceId执行uni.closeBLEConnection，并等待其success回调（哪怕当前已断开） - 不要依赖“连接失败就跳过关闭”，失败也可能已建立半连接状态
- 建议封装成带兜底的连接函数：
ensureClosedThenConnect(deviceId)，内部先close再create
断连后不能立刻重试，要加退避延迟和状态校验
蓝牙适配器底层需要时间释放资源，立即重试等于雪上加霜。实测发现，华为 Mate20、红米 8A 等机型在连续失败 3 次后，若间隔 ≤1s，基本必进“5 秒死循环”状态。
- 重试前必须检查
uni.getConnectedBluetoothDevices，确认目标设备确实不在已连接列表中 - 首次失败后至少等待 1500ms；第二次失败后延至 3000ms；第三次起启用指数退避（如 5000ms、8000ms）
- 避免在
onBLEConnectionStateChange的断开回调里直接发起重连——该事件可能在系统尚未完全释放连接时就触发
安卓必须关掉“后台扫描残留”，否则搜索和连接互相干扰
uni.startBluetoothDevicesDiscovery 不只是“搜设备”，它会持续占用 BLE 控制通道。如果搜完没及时 stopBluetoothDevicesDiscovery，即使你只连一个设备，系统也会因资源争抢拒绝新连接请求，错误码常为 10003 connection fail 或静默超时。
- 每次成功获取到目标设备后，**立刻**调用
uni.stopBluetoothDevicesDiscovery，不要等连接完成后再停 - 在页面
onHide或蓝牙模块退出时，也要主动stop，防止用户切后台后扫描仍在运行 - 某些安卓 ROM（如 EMUI、MIUI）会在扫描中自动限制连接 API 调用频次，停扫是绕过该限制的唯一可靠方式
最易被忽略的一点：部分蓝牙打印机（尤其是国产热敏款）在断电重启后 deviceId 会变，但 uni-app 缓存的旧 deviceId 仍保留在 getConnectedBluetoothDevices 结果里。此时你对着一个已失效的 ID 死命重连，自然永远超时——得结合设备名或 service UUID 做二次校验，而不是无脑复用上次存的 deviceId。
