JavaScript分片上传断点续传的核心是记录已传分片、跳过成功部分、单独重试失败分片并保持服务端状态一致；需前端查询上传状态、缓存分片状态、存localStorage，服务端校验分片唯一性与幂等性，配合指数退避重试及合并后清理。
JavaScript 中实现分片上传失败后的断点续传重试，核心在于：**记录已成功上传的分片、跳过已传部分、对失败分片单独重试，并保持服务端状态一致**。不能简单重新上传整个文件，也不能盲目重试所有分片。
1. 前端需维护分片上传状态
每次上传前，先向服务端发起「查询已上传分片」请求（例如 GET /upload/status?uploadId=xxx），获取已成功接收的分片序号列表（如 [0, 1, 3, 4]）。前端据此跳过这些分片，只提交缺失或失败的分片（如第2、第5片）。
- 用
Map或数组缓存每个分片的上传状态（pending/success/failed） - 上传时在请求头或参数中带上分片序号（
chunkIndex）、总片数（totalChunks）、唯一上传 ID（uploadId） - 避免因页面刷新丢失状态——可将
uploadId和已传分片存入localStorage（注意敏感信息不存）
2. 服务端必须支持分片校验与幂等接收
服务端不能只靠分片序号判断是否重复，而应结合：文件唯一标识（如文件 hash 或 uploadId + 文件名 + 大小）+ 分片序号 + 分片内容 hash（如 MD5 或 SHA-256）。这样即使同一分片重传多次，也能安全识别并丢弃冗余请求。
- 接收分片时，先查该分片是否已存在且内容一致；若一致直接返回 success，不写磁盘
- 合并前校验所有分片是否齐全、每片 hash 是否匹配，防止中间篡改或错片
- 为每个上传会话设置过期时间（如 24 小时），超时自动清理临时分片
3. 失败分片的智能重试策略
不是所有失败都立刻重试。网络抖动可重试，但 403 或 412（预检失败）等业务错误需先处理原因。建议按以下逻辑执行：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
- 对单个分片最多重试 3 次，间隔指数退避（如 1s → 3s → 9s）
- 使用
AbortController控制单次请求超时（如 30 秒），超时后标记为 failed 并触发重试 - 若连续多个分片失败（如连续 2 片 500），暂停上传，提示用户检查网络或稍后重试
- 重试时复用原请求参数（含相同
uploadId和chunkIndex），确保服务端能关联上下文
4. 合并完成后的最终确认与清理
所有分片上传成功后，前端调用「合并接口」（如 POST /upload/merge）。服务端执行合并、计算完整文件 hash、保存元数据。此时需：
- 合并成功后，前端立即清除本地
localStorage中对应的上传状态 - 合并失败（如某分片被误删）应返回具体缺失的分片序号，前端可再次拉取状态并补传
- 提供「强制刷新状态」按钮，供用户手动触发
GET /upload/status重建本地进度
不复杂但容易忽略。关键不在“怎么重传”，而在“怎么知道该传谁”和“传了能不能算数”。前后端配合对齐状态，比堆 retry 逻辑更重要。
