UniApp BLE 稳定连接需三要素：全局监听 onBLEConnectionStateChange 并主动 close 连接；每45秒发心跳包防设备休眠；连接后设 MTU 为512并串行写入。
频繁断开不是设备“坏了”，而是连接状态没被主动管理——UniApp 的 BLE 连接默认不保活，系统或设备端一松手就掉，必须靠代码兜底。
onBLEConnectionStateChange 必须全局监听
这是所有稳定性的起点。不监听这个事件，等于闭眼开车：系统悄悄断连了，你还在往已失效的连接里写数据。
- 在
App.vue的onLaunch或onShow中注册，确保生命周期内始终有效 - 回调里必须区分
res.connected === false和res.connected === true两种情况，不能只处理断开 - 断开时别只打日志，要立刻调用
uni.closeBLEConnection({ deviceId: res.deviceId })清理残留句柄，否则下次createBLEConnection会报"fail already connect" - 部分安卓厂商（如华为 EMUI）可能延迟触发该事件，建议搭配定时心跳做兜底
连接后必须发心跳包防休眠
很多 BLE 设备（尤其是低功耗打印机、传感器）在 60–120 秒无通信后自动进入休眠，此时连接看似存在，但写入成功却无响应——实际是设备没醒。
- 心跳指令不一定要有业务意义，比如向一个只读特征值发一次
read，或向控制特征值写一个固定字节（如0x00） - 使用
setInterval每 45 秒触发一次，比设备休眠阈值更激进一点 - 心跳前先检查连接状态：
uni.getConnectedBluetoothDevices返回空数组就说明已断，直接走重连逻辑 - 避免在页面 onHide 时停心跳——后台运行时设备仍需保活
重连逻辑要绕过“已连接”错误
createBLEConnection:fail already connect 错误本质是系统层连接未释放，而 uni-app 层状态不同步。不能只 catch 错误，得主动清理。
- 每次重连前，强制执行
uni.closeBLEConnection，即使失败也继续下一步 - 加
setTimeout(..., 300)延迟再createBLEConnection，给系统释放资源留出时间窗口 - 如果
closeBLEConnection回调不触发（某些小米/OPPO 机型），降级使用plus.bluetooth.closeBLEConnection（5+ API） - 重试次数建议设上限（如 3 次），避免无限循环卡死主线程
MTU 协商和写入队列必须做
断开常发生在大数据传输中途，根源是 MTU 默认值（23 字节）太小，导致分包失败或超时；同时并发写入会压垮设备缓存。
- 连接成功后立即调用
uni.setBLEMTU，目标值设为512（需设备支持），能显著降低分包频率 - 所有写操作必须串行化：用 Promise 链或 async/await 控制，确保
writeBLECharacteristicValue上一个 success 后再发下一个 - 不要依赖
success就认为设备已处理完成——有些设备需要几百毫秒响应，加await new Promise(r => setTimeout(r, 200))再发下一条更稳妥 - 遇到
write失败（如 errCode 10007），先close再重连，别硬 retry
最易被忽略的一点：断开未必发生在“写数据时”，而常藏在“你以为连接还活着”的间隙里。状态监听 + 心跳 + 主动 close，三者缺一不可——少一个，设备就敢在你点击按钮的瞬间睡过去。
