Pinia Actions 通过封装分片计算、并发调度、断点续传和合并逻辑实现大文件上传；利用 spark-md5 增量哈希、2–5MB 分片、Promise 并发池（如限 3 个）、AbortController 暂停恢复及 /upload/merge 收尾。
Pinia Actions 本身不直接处理文件上传或并发逻辑，它只是组织和暴露状态与业务方法的容器。真正实现大文件分片上传的并发控制，靠的是在 Action 内部封装的 JavaScript 控制逻辑——比如分片调度、Promise 并发池、中断恢复、进度更新等。关键在于：把上传流程拆解为可管理的状态单元，再用 Pinia 统一驱动。
分片计算与唯一标识生成
在 Action 中先完成文件切片和哈希计算，避免阻塞主线程：
- 用 spark-md5 增量读取（每 2MB 一段），边读边算 MD5，不把整个文件 load 进内存
- 切片大小建议设为 2–5MB，兼顾 HTTP 稳定性与并发粒度
- 每个分片带元信息：index（序号）、hash（文件级 MD5）、chunkHash（可选，单片哈希用于校验）
并发上传调度器（核心）
在 Action 里实现一个轻量级并发池，控制同时进行的请求数（如最多 3 个）：
- 维护一个待上传分片队列（
pendingChunks: Chunk[]）和一个运行中 Promise Set - 每次从队列取一个分片，发起
fetch或axios请求，成功后标记为uploaded并更新进度 - 用
Promise.race()或自定义重试逻辑处理失败分片，失败后自动重入队列（可限重试次数） - 不依赖全局变量，所有状态都通过
store的state和actions管理，保证响应式更新
断点续传与暂停恢复
利用 Pinia 的响应式能力，把上传上下文持久化到 store 中：
- 初始化时调用
/upload/init，拿到已上传分片列表，过滤掉已成功的分片，只保留pendingChunks - 暂停时清空运行中请求（
AbortController），但不清理 state，保留uploaded和progress - 恢复时重新触发调度器，只上传剩余分片；用户切换页面再回来，也能从 store 恢复进度
合并与收尾通知
当所有分片上传完成，Action 触发合并请求：
- 检查
uploaded.length === totalChunks，避免漏片 - 调用
/upload/merge，传入fileHash和filename - 合并成功后，清除临时分片状态，更新文件记录为
status: 'done'，并通知 UI 跳转或提示
