pinia 适合管理分片上传的状态与进度而非执行上传，需定义四层进度字段、队列管理、防抖更新及加权总进度计算，并通过状态聚合支持多文件联动。
Pinia 本身不直接处理文件上传逻辑，但它非常适合管理分片上传过程中的进度、队列、状态切换和跨组件同步。关键不是让 Pinia 去发请求或切片，而是用它来统一承载和响应上传生命周期的可变事实——比如“第3个文件正在传第17片”“总进度72%”“网络断开，已缓存3个待重试任务”。
状态结构要覆盖四层真实进度
不要只存一个 progress: number。参考响应式分片上传的四层模型，在 Pinia store 中定义对应字段：
-
本地分片索引层：记录每个文件已成功提交的分片数（
uploadedChunks: number）、总片数（totalChunks: number），用于计算基础进度 -
当前分片流层：为正在上传的分片单独存
currentChunkProgress: number（0–100），配合isUploadingChunk: boolean触发局部 UI 更新 -
服务端确认层：维护
confirmedChunks: number[]数组，每次分片上传成功后由后端返回确认索引，前端据此跳过已落盘分片 -
合并状态层：添加
mergeStatus: 'idle' | 'merging' | 'merged' | 'failed'和mergeProgress: number，用于合并阶段独立反馈
队列管理要支持并发与中断恢复
大文件上传常需多文件并行或单文件多分片并发。Pinia store 中建议用数组+对象组合管理队列：
- 用
uploadQueue: UploadTask[]存所有待上传任务，每个UploadTask包含id、file、status: 'pending' | 'uploading' | 'paused' | 'done' | 'error'、progress等 - 用
activeTasks: Set<string></string>快速判断哪些任务正在运行，避免重复触发 - 页面刷新后，通过初始化时调用
resumeFromServer()（如请求/upload/status?hash=xxx）自动填充confirmedChunks并重置status为'paused'，用户点击“继续”即可续传
进度更新必须防抖且非线性映射
浏览器原生 onprogress 频率高、抖动大，直接绑定到 Pinia 会导致频繁 re-render。正确做法是：
- 在上传逻辑中加节流（如 300ms 内最多更新一次
currentChunkProgress），再 commit 到 store - 总进度条不要用简单公式：
(uploadedChunks / totalChunks) * 100。应按阶段加权，例如：
— 分片上传占 90%，每片平均贡献90 / totalChunks
— 合并校验占 10%，合并开始后从 90% 平滑推进至 100% - 在 store 的
computed或getters中封装最终展示进度，便于复用和测试
多文件联动靠状态聚合与事件解耦
当同时上传多个大文件时，用户既要看单个文件卡片的细节，也要看整体队列概览。Pinia 可这样组织：
- 每个文件用独立
FileItem对象管理自身状态（含分片进度、错误信息、暂停控制） - 提供
getters如overallProgress（加权平均）、queueSummary（如 “2 完成，1 上传中（68%），1 暂停”） - 不依赖全局事件总线。用
watch监听关键状态变化（如某文件status === 'done'），触发通知或自动启动下一个任务
