Pinia Actions 不直接处理传感器数据流，而是接收由 Composition API 或专用 Hook（如 useAccelerometer）采集并标准化的数据，执行状态更新、业务响应与异步分发，并通过 $onAction 实现可观测性。
Pinia Actions 本身不直接处理传感器数据流，它不是事件总线或实时数据管道。处理传感器数据流（如加速度计、陀螺仪、地理位置、蓝牙设备上报等）的核心应在组件或专用逻辑层完成监听与采集，Actions 的角色是接收、归一化、状态托管与分发决策，而非主动拉取或订阅原生传感器流。
传感器数据应由 Composition API 或专用 Hook 封装监听
浏览器或移动端 SDK（如 navigator.geolocation、DeviceOrientationEvent、BluetoothRemoteGATTCharacteristic）提供的传感器数据是持续触发的事件流，需用 watchEffect、onMounted 或自定义 Hook（如 useAccelerometer()）来建立和管理监听器。这些 Hook 负责：
- 申请权限并初始化传感器监听
- 节流/防抖高频事件（如每 100ms 取一次 orientation）
- 格式标准化（统一为
{ x: number, y: number, z: number, timestamp: number }） - 在
onUnmounted中自动清理监听器，防止内存泄漏
Actions 接收数据并驱动状态更新与业务响应
一旦传感器数据经 Hook 处理后就绪，应通过调用 store 的 Action 进行注入。Action 不做采集，只做“承上启下”：
- 接收标准化数据包作为参数（例如
updateMotionData(payload)） - 写入 state 字段（如
this.motion = { ...payload, lastUpdate: Date.now() }） - 根据业务规则触发副作用：比如当加速度突变超过阈值时，调用
this.startRecording()；或当 GPS 定位精度低于 10 米时，设置this.locationWarning = true - 避免在 Action 内重复监听传感器——那会破坏单一职责，也导致多实例冲突
需要异步协调时，用 Action 封装“带条件的数据分发”
若传感器数据需转发至后端、本地数据库或跨 Tab 同步，这类 I/O 操作适合封装在 async Action 中：
- 例如
async syncSensorBatch(batch: SensorPoint[])：收集一批点位后批量上传 - 内部使用
await api.post('/sensor/log', { points: batch })，并管理isSyncing和syncError状态 - 可结合
AbortController支持手动中断上传（如用户切后台时） - 上传成功后，可调用
this.$patch({ lastSyncTime: new Date() })更新元状态
配合 $onAction 实现传感器链路可观测性
为保障传感器相关逻辑的稳定性，建议对关键 Action（如 updateMotionData、syncSensorBatch）启用 $onAction 监控：
- 记录每次数据注入的时间戳、采样频率、有效字段数，用于识别丢帧或延迟异常
- 在
onError中捕获序列化失败、网络超时、存储写入错误等，并打上sensor: 'accelerometer'标签上报 - 利用
before钩子检查数据质量（如全零值、timestamp 倒退），提前 warn 或丢弃
