必须每次写入前用uni.getconnectedbluetoothdevices确认设备真实连接，动态获取服务与特征值，cpcl指令需带\r\n并转arraybuffer，空闲超60秒须发心跳唤醒。
先确认蓝牙适配器和连接状态是否真实就绪
很多“写入成功但设备没反应”的情况，根本不是数据发错了，而是连接早已断开或压根没真正建立。uni-app 的 writeBLECharacteristicValue 只校验本地连接缓存，不校验物理链路——即使设备已掉线，API 仍可能返回 success。
- 每次调用
writeBLECharacteristicValue前，必须主动检查连接状态：uni.getConnectedBluetoothDevices({deviceId: 'xxx'})，确认返回列表中包含该设备且connected === true - 不要依赖
onBLEConnectionStateChange的单次回调：iOS 有时不触发断连事件，安卓在省电模式下也会静默断开 - 若发现设备不在已连接列表中，别重试写入，直接走重连流程：
uni.createBLEConnection+setTimeout(..., 800)+ 重新发现服务与特征值
服务与特征值必须动态获取，不能硬编码 UUID
CPCL 打印机、ESC/POS 热敏打印机等常见设备，服务 UUID 并非固定不变。部分固件会隐藏标准串口服务 00001101-0000-1000-8000-00805F9B34FB，或要求先连自定义服务（如 0000FF00-0000-1000-8000-00805F9B34FB）再跳转。硬写 UUID 在红米、华为等机型上极易导致 services 为空。
- 连接成功后，必须调用
uni.getBLEDeviceServices获取真实服务列表，再遍历匹配，而非直接用预设值 - 查特征值时，重点筛选
properties.write === true && properties.notify === false的项（CPCL 是单向写入） - 若
res.services为空，立即重连，不要往下执行；某些设备需重连 2–3 次才能稳定暴露服务
CPCL 指令必须带 \r\n 且整体转 ArrayBuffer 发送
CPCL 是行协议，每条指令必须以 \r\n 结尾，且整个字符串必须转为 ArrayBuffer。用 \n 或漏换行，设备会静默丢弃后续指令；传字符串或十六进制数组，writeBLECharacteristicValue 会报 invalidData 或无响应。
- 拼接指令时显式加
\r\n："TEXT 24 0 30 50 Hello\r\nBARCODE 128\r\n" - 发送前统一转码：
new TextEncoder().encode(str).buffer（H5、App、小程序均支持） - 禁止混用 ZPL 语法（如
^XA），CPCL 不识别；也别发空行或纯空白字符串
长时间空闲后写入失败，大概率是服务特性休眠
BLE 设备（尤其是热敏打印机）在 1–3 分钟无操作后，会关闭写入通道以省电。此时连接状态仍是 connected === true，但 writeBLECharacteristicValue 实际无效。
- 解决方案不是重连，而是“唤醒”：在用户操作间隔超过 60 秒时，主动发一条轻量指令（如
"STATUS\r\n"或空指令"\r\n"）试探通道 - 更稳妥的做法是加心跳包：每 45 秒向设备写一次
"\r\n"，保持特性活跃 - 注意指令间隔——部分设备要求两次写入间隔 ≥ 200ms，太快会丢弃，可用
setTimeout控制节奏
