cpcl打印机在uni-app中连不上主要因蓝牙状态校验、服务发现或换行符错误：须先调uni.getbluetoothadapterstate确认可用，再动态发现服务与特征值，cpcl指令末尾必须用\r\n并转arraybuffer发送，每次写入前需校验连接状态。
CPCL 打印机在 uni-app App 端连不上、发不出指令，90% 是卡在蓝牙状态校验、服务发现或换行符格式上——不是 API 调用顺序错了，而是关键判断被跳过了。
uni.getBluetoothAdapterState 必须先于 uni.openBluetoothAdapter 调用
很多人以为 uni.openBluetoothAdapter 就是“打开蓝牙”，其实它只是触发初始化请求；iOS 首次运行会弹授权框，安卓可能返回 poweredOff: true 或 available: false，此时直接搜设备必然失败。
- 必须先调用
uni.getBluetoothAdapterState，在 success 回调里检查res.available === true - 若
res.discovering === true，得先uni.stopBluetoothDevicesDiscovery()再启动新搜索，否则安卓/iOS 都不触发设备发现回调 - 若
res.poweredOff === true，不能只调uni.openBluetoothAdapter，要引导用户去系统设置手动开启蓝牙（uni.showToast提示“请前往手机设置开启蓝牙”）
服务与特征值必须动态获取，不能硬编码 UUID
CPCL 打印机（如芝柯 ZJ-5890、精臣 Q1）虽然常用标准串口服务 00001101-0000-1000-8000-00805F9B34FB，但部分固件会隐藏该服务，或要求先发现 0000FF00-0000-1000-8000-00805F9B34FB 再跳转。硬写 UUID 在红米 Note 系列等机型上极易返回空服务列表。
-
uni.createBLEConnection成功后，必须加setTimeout(() => { ... }, 800)再查服务，避免服务缓存未刷新 - 查服务前加判空：
if (!res.services || res.services.length === 0)，为空就重连，别往下走 - 查特征值时重点筛选
properties.write === true && properties.notify === false的项（CPCL 是单向写入，不需要 notify）
CPCL 指令必须用 \r\n 换行，且整体转为 ArrayBuffer 发送
CPCL 是逐行解析的指令流，"TEXT 24 0 30 50 Hello" + "BARCODE 128" 中间没换行，打印机直接忽略第二条；更隐蔽的是换行符类型：uni-app 默认用 \n，但底层蓝牙协议要求 \r\n。
- 每条 CPCL 指令末尾必须显式拼接
\r\n，例如："TEXT 24 0 30 50 Hello\r\nBARCODE 128\r\n" - 发送前必须转成
ArrayBuffer：new TextEncoder().encode(str).buffer（H5 和小程序环境都支持） - 不要混用 ZPL 语法（如
^XA），CPCL 不识别；也不要发空指令或纯空白行
每次写入前必须 checkConnection，不能依赖连接状态缓存
App 端蓝牙连接极不稳定：切后台、锁屏、系统省电策略都可能导致连接静默断开。很多开发者在 uni.createBLEConnection 成功后就一直用同一个 deviceId 发送，结果某次打印突然无响应——实际连接早已失效。
- 每次调用
uni.writeBLECharacteristicValue前，必须先执行uni.getConnectedBluetoothDevices并检查目标deviceId是否仍在返回列表中 - 若不在，需重新
uni.createBLEConnection，不能跳过重连直接写 - 写入失败时，
fail回调里的err.errCode常见值有：10001（连接已断）、10002（特征值不可写）、10006（参数非法），要按 errCode 分类处理
最易被忽略的是：红米/OPPO 等厂商定制系统对 BLE 服务发现有额外延迟，且 iOS 在后台时无法维持 notify 订阅——这意味着 CPCL 打印这种单次写入场景虽能跑通，但一旦涉及状态反馈（比如打印完成通知），就必须设计超时重试和连接保活逻辑。
