响应式分片上传进度分为四层：本地分片索引层、当前分片流层、服务端确认层、合并状态层；交互反馈需真实、防抖、低延迟，通过非线性映射、中断恢复可视化、多文件队列联动及轻量级轮询同步实现一致性体验。
响应式系统处理大文件分片上传进度，核心不是“等上传完成再更新”，而是把进度拆解为可感知、可计算、可同步的多个层次——前端切片状态、单片传输流、已持久化分片数、服务端合并确认。交互反馈则围绕这四个层次构建真实、防抖、低延迟的视觉与行为响应。
分片上传进度的四层计算逻辑
传统 onprogress 只反映浏览器发出的数据量，对用户无意义。响应式系统需叠加以下四层数据源：
- 本地分片索引层：已成功提交的分片数量（如 12/58），结合分片大小（如 4MB）得出已上传字节数
-
当前分片流层：对正在上传的分片启用
XMLHttpRequest.upload.onprogress或fetch的ReadableStream拆包监听，实时获取该分片的发送百分比 - 服务端确认层：每次分片上传成功后，后端返回该分片的存储确认（如写入 MinIO/OSS 成功 + MD5 校验通过），前端据此更新“已落盘分片列表”
-
合并状态层：调用
/merge?hash=xxx后轮询或由服务端 WebSocket 推送合并进度（如“正在拼接第42块→校验中→生成最终文件”）
交互反馈的关键实现点
用户拖动文件、点击上传、网络中断、重试成功……每个动作都应触发明确、不闪烁、有上下文的反馈：
- 上传前校验即反馈：计算文件 SHA-256 同时显示“正在验证指纹…”，避免用户误以为卡死；若秒传命中，直接跳转到“上传完成”态并高亮提示“已秒传，无需重复上传”
-
进度条非线性映射：不要简单用
(uploadedChunks / totalChunks) * 100。例如：前 90% 是分片上传，最后 10% 是合并+校验，可在合并阶段将进度从 90% 平滑推进至 100%，防止“卡在 99%”引发焦虑 - 中断恢复可视化：网络断开时，进度条暂停并显示“已上传 37/58 片”，按钮文字变为“继续上传”而非“重新开始”；恢复后自动续传，且进度条从断点处平滑加速进入下一阶段
- 多文件队列状态联动：当并发上传 3 个大文件时，每个文件卡片独立显示其分片进度；总进度条显示“3 个任务：2 完成，1 进行中（72%）”，避免全局进度误导
真实可用的轻量级进度同步方案
不用强依赖 WebSocket，也能做到准实时反馈：
- 前端每上传完一个分片，立即向后端发起一次轻量
GET /upload/status?hash=xxx，返回{ uploaded: [0,1,3,4,...], merged: false } - 合并请求发出后，前端启动 1.5s 间隔轮询
/merge/status?hash=xxx，直到返回merged: true或超时 - 所有接口响应头统一携带
X-Upload-Progress: 78.3，前端可直接读取，避免重复计算逻辑 - 进度数值始终保留两位小数（
78.30%），视觉上更稳定；变化小于 0.1% 时不触发 DOM 更新，防抖渲染
响应式系统里的进度，本质是用户认知与系统状态之间的一致性协议。它不追求毫秒级刷新，而追求每一次状态变更都有据可查、有迹可循、有反馈可感。
