Pinia 通过集中式响应式 store 统一管理播放列表与进度状态：列表以结构化数组存储并维护 currentTrackIndex，提供增删改 action 和持久化支持；进度由 store 托管 currentTime 等字段，支持实时同步与跨组件响应；两者通过 playNext 等 action 联动，并在 Electron 中通过 IPC 封装主进程协作。
Pinia 通过定义一个集中、响应式的 store 来统一管理播放列表和播放进度，避免状态分散在多个组件中导致不同步或重复逻辑。
播放列表状态：结构化存储与动态更新
播放列表不是简单存个数组，而是需要带索引、可检索、支持增删改的结构化数据。在 Pinia store 中通常这样设计：
- 用数组保存完整歌曲列表（含 title、artist、path、duration 等字段）
- 额外维护 currentTrackIndex（当前播放项下标），而非只存当前歌曲对象——便于上一首/下一首逻辑计算
- 提供 addTrack、removeTrack、replaceList 等 action，所有修改都走统一入口，触发响应式更新
- 支持持久化：在 addTrack 或 replaceList 后，可调用 localStorage 或 Electron 的 IPC 将列表结构写入本地（注意不存文件路径以外的敏感内容）
播放进度状态：实时同步与跨组件感知
进度不是只在播放器组件里读取 audio.currentTime，而是由 store 统一托管并驱动更新：
- store 中定义 currentTime、duration、isPlaying、isSeeking 等字段
- 使用 setInterval 或 requestAnimationFrame 定期更新 currentTime（也可由音频元素的 timeupdate 事件触发 commit）
- 所有 UI 组件（如进度条、时间显示、迷你播放栏）直接读取 store 中的 currentTime，无需 props 传递或事件监听
- 拖拽进度条时，先设 isSeeking = true，再调用 action 更新 currentTime，并通知 audio 元素跳转；结束后恢复自动更新
列表与进度的联动逻辑
两者不是孤立存在，而是通过 store 内部 action 实现强耦合：
- 调用 playNext() 时，自动重置 currentTime = 0，并更新 currentTrackIndex
- 切换歌曲后，store 可主动触发一次元数据加载（如用 music-metadata 解析新文件），更新 duration 和封面等信息
- 若启用了“单曲循环”，next 操作不改变 index，只重置 currentTime；“随机播放”则生成新 index 并校验边界
- 播放暂停时，store 保留当前 currentTime；恢复播放即从该点继续，无需额外缓存
Electron 环境下的特别处理
在桌面端，还需考虑主进程与渲染进程协作：
- 播放控制（play/pause/seek）的底层操作仍在渲染进程的 audio 元素上执行
- 但关键状态变更（如播放完成触发下一首）建议由 store 的 action 触发，并通过 preload 暴露的 ipcRenderer 发送事件给主进程做日志记录或系统通知
- 避免在 store 中直接调用 require('electron')，保持逻辑纯净；IPC 调用封装在 action 内部即可
