errcode=133是android专属ble连接失败码，源于系统gatt层资源冲突，需先扫描再连接、失败后延时800ms重试、监听断连事件并清理句柄。
uni-app里errCode=133是Android专属连接失败码
这个错误不会出现在iOS或小程序端，只在Android真机上发生，本质是系统GATT层资源冲突或状态异常。它和uni-app代码逻辑无关，而是底层蓝牙协议栈拒绝建立新连接——常见于设备刚重启蓝牙、或前一次连接未彻底释放时。
必须在createBLEConnection前触发一次扫描
很多开发者以为“已知deviceId就能直连”，但在部分Android机型（尤其是OPPO、vivo、华为EMUI 12+）上，系统要求设备地址必须出现在最近一次扫描结果中，否则直接返回errCode=133。这不是bug，是厂商ROM对BLE协议栈的强化校验。
- 调用
uni.startBluetoothDevicesDiscovery({services: [], allowDuplicatesKey: false}) - 立即注册
uni.onBluetoothDeviceFound监听，并在回调里缓存目标<pre class="brush:php;toolbar:false;">deviceId</pre> - 收到目标设备后，立刻
uni.stopBluetoothDevicesDiscovery() - 再调用
uni.createBLEConnection({deviceId: xxx})
连接失败后不能立即重试
Android系统对BLE连接有频率限制：连续两次createBLEConnection间隔若小于500ms，高概率触发<code>errCode=133。这不是uni-app能绕过的，是Linux内核蓝牙子系统（BlueZ）的保护机制。
- 每次
fail回调中，必须清空旧连接句柄（即使没显式保存） - 加
setTimeout延时至少800ms再发起下一次连接 - 若连续失败3次，建议提示用户“请关闭再打开手机蓝牙”并重置适配器：
uni.closeBluetoothAdapter()→uni.openBluetoothAdapter()
别忽略onBLEConnectionStateChange里的断连兜底
errCode=133常伴随静默断连：连接看似成功，但几秒后onBLEConnectionStateChange抛出connected: false。如果没监听这个事件，后续writeBLECharacteristicValue就会报errCode=10006，让人误以为是写入问题。
- 必须在
createBLEConnection的success回调里，立刻绑定uni.onBLEConnectionStateChange - 当
connected: false时，同步调用uni.closeBLEConnection，避免句柄残留 - 某些设备（如ZJ-5890热敏打印机）在连接后需等待2秒才真正就绪，此时直接写数据也会被系统拦截
最易被忽略的是：errCode=133从不抛出errMsg，只返回空字符串。你得靠console.log打点确认是否进了fail分支——别依赖Toast提示来判断失败。
