Pinia 的 state 仅管理蓝牙设备列表的共享状态而非执行连接操作；应定义 pairedDevices、scanningDevices、isScanning、connectingTo 和 error 等字段，配合 action 更新并可选持久化 pairedDevices。
Pinia 的 state 本身不直接处理蓝牙连接，而是用来管理蓝牙设备列表的共享状态——比如已配对设备、正在扫描的设备、连接状态、最后连接时间等。它不执行扫描或配对动作（那是原生蓝牙 API 或 SDK 的职责），但为整个应用提供统一、响应式、可持久化的设备列表容器。
蓝牙设备列表该存哪些字段？
建议在 state 中定义结构清晰、可扩展的数组和辅助状态：
-
pairedDevices：已成功配对并保存的设备列表，每项至少含
id（MAC 地址或唯一标识）、name、isConnected、lastConnectedAt -
scanningDevices：当前扫描到但未配对的临时设备列表，含
id、name、rssi（信号强度） - isScanning：布尔值，控制 UI 显示“搜索中”或“停止扫描”按钮
- connectingTo：记录当前正在连接的设备 ID，用于防重复点击或显示加载态
- error：最近一次蓝牙操作的错误信息（如 “timeout”、“permission denied”），便于统一提示
如何让设备列表响应真实蓝牙行为？
state 只是“数据容器”，必须配合外部逻辑更新。典型做法是：
- 在调用原生蓝牙 API（如 Capacitor BluetoothLE、@capacitor-community/bluetooth-le 或微信小程序蓝牙接口）成功发现设备后，调用 store 的 action（如
addScanningDevice()）写入scanningDevices - 配对成功后，调用
addPairedDevice()将设备移入pairedDevices，并清除对应临时项 - 连接状态变更（如断开、重连失败）通过监听系统事件触发
updateConnectionStatus()，修改isConnected和lastConnectedAt - 所有写操作都应在 action 内完成，确保逻辑集中、可追踪、可测试
要不要持久化？怎么存？
已配对设备列表建议持久化，避免每次启动重新配对；扫描列表则无需保存。
- 使用
pinia-plugin-persistedstate插件，仅对pairedDevices字段启用 localStorage 持久化 - 注意敏感字段：不要存密钥、token 或用户凭证；MAC 地址若涉及隐私，可做哈希脱敏再存储
- 首次加载时，从 localStorage 恢复
pairedDevices，同时清空过期项（例如 30 天未连接的设备）
组件中怎么安全读写？
避免直接修改 state 对象，推荐以下方式：
- 读取：用
storeToRefs()解构响应式引用，保持响应性 - 修改：只通过 action 方法（如
removePairedDevice(id)）触发，不在组件内写store.pairedDevices = [...] - 批量更新：对
pairedDevices使用$patch()进行对象级更新，比全量替换更高效 - 重置：调试时可用
$reset()清空所有设备，但生产环境慎用
