分片上传失败后只重传对应分片而非整文件，核心在于前端精准识别失败分片（通过chunkIndex和uploadId）、持久化状态、自动+手动重试，服务端幂等接收并校验。
分片上传失败后只重试出错的那一片，而不是整个文件重传——这是分片上传最核心的实用价值。关键在于前端要能精准识别哪个分片失败、记录状态、并支持单独发起重传请求。
明确失败分片并标记状态
每个分片上传都应携带唯一索引（chunkIndex）和文件标识（如fileHash或uploadId）。上传响应需返回明确结果：成功、已存在（skip）、校验失败或服务端错误。前端用数组或 Map 存储各分片状态，例如：
- { index: 0, status: 'success' }
- { index: 5, status: 'failed', error: 'network timeout' }
- { index: 12, status: 'skipped' }
失败分片的状态必须持久化（如存入 localStorage 或 Pinia store），否则页面刷新后无法续传。
自动重试 + 手动触发双机制
重试不应依赖用户点击“重试”按钮才开始，而应默认自动进行（带退避策略），同时保留手动干预入口：
立即学习“前端免费学习笔记（深入）”；
- 单次失败后立即重试 1 次；若仍失败，间隔 1s → 3s → 5s 递增重试，最多 3 轮
- 重试时复用原分片参数（index、start/end 字节范围、blob），不重新切片
- 界面显示“第5片上传失败，正在重试…”并高亮对应进度条段落
- 提供“重试全部失败分片”按钮，供用户主动干预
服务端配合：避免重复写入与校验绕过
重试请求到达服务端时，不能简单当作新请求处理，否则可能造成同一分片被多次保存或覆盖。服务端需支持：
- 根据 fileHash + chunkIndex 查询该分片是否已接收并校验通过，若是则直接返回 success
- 若已存在但校验失败（如MD5不匹配），则允许覆盖写入，确保数据最终一致
- 拒绝无校验的裸重传，强制携带分片哈希（chunkHash）用于服务端二次校验
这样前端重试无论发几次，服务端都能幂等响应，既保障可靠性，又不增加冗余IO。
失败聚合与降级提示
连续重试仍失败的分片需要汇总反馈，避免让用户陷入“一直重试”的假象：
- 当某一分片累计失败 ≥3 次，停止自动重试，将其归入“永久失败列表”
- 上传结束后统一提示：“共1个分片上传失败（#5），可检查网络后点击【重试】或联系管理员”
- 提供导出失败日志功能（含时间、分片号、错误码、响应体），便于排查弱网、代理拦截等真实原因
