断点续传需手动实现：1. 文件切片并生成唯一uploadid；2. 上传前查询服务端已传分片；3. 分片上传配合指数退避等智能重试；4. 合并时校验并支持针对性重传。
Fetch 本身不支持断点续传，也无法直接读取或恢复上传中的文件分片；实现断点续传与智能重试，需要你主动将大文件切片、记录已上传进度、校验服务端状态，并在失败时只重传未完成的分片。
1. 文件切片与唯一标识生成
上传前需将文件按固定大小（如 5MB）切分为 Blob 分片，并为整个上传任务生成唯一 ID（如基于文件名 + 大小 + 最后修改时间的 hash），便于服务端识别同一任务：
- 用 File.prototype.slice() 获取每个分片（注意兼容性，推荐用 file.slice(start, end)）
- 用 crypto.subtle.digest('SHA-256', ...) 或轻量库（如 spark-md5）计算文件整体 hash，作为 uploadId
- 每个分片带上 index、total、uploadId、chunkHash（可选），方便服务端校验和排序
2. 上传前查询服务端已传分片
发起上传前，先发一次 GET 请求到 /api/upload/status?uploadId=xxx，服务端返回已成功接收的分片 index 列表（如 [0, 1, 3, 4]）。客户端据此跳过这些分片，只上传缺失的（如 2、5、6…）：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 该请求应带 cache: 'no-store' 防止误用缓存
- 若网络失败或超时，可降级为全量重试，或等待几秒后重查（最多 2 次）
- 服务端需持久化分片状态（如 Redis 或数据库），并设置合理过期时间（如 24 小时）
3. 分片上传 + 可控重试策略
对每个待传分片调用 fetch，失败时不立即放弃，而是根据错误类型差异化处理：
- 网络中断 / 503 / 超时：延迟 1s、2s、4s 指数退避重试（最多 3 次），避免雪崩
- 401 / 403：触发 token 刷新逻辑，刷新成功后重发当前分片
- 400 / 409 / 500：记录错误详情，终止上传并提示用户（如校验失败、服务异常）
- 每次 fetch 显式设置 signal（配合 AbortController），便于手动中止或超时控制
4. 合并与最终校验
所有分片上传完成后，调用合并接口（如 POST /api/upload/merge），携带 uploadId 和完整分片列表。服务端执行校验（如拼接后比对总 hash），成功则返回文件 URL；失败则返回缺失或损坏的分片索引，前端可针对性重传：
- 合并请求也需重试（最多 2 次），因可能只是临时调度延迟
- 客户端可本地缓存 uploadId → 文件元信息映射，防止页面刷新后丢失进度
- 建议服务端返回每个分片的 ETag 或 checksum，供前端上传后自行比对，增强可靠性
不复杂但容易忽略：断点续传的关键不在“怎么传”，而在于“怎么知道传到哪了”——前后端必须就 uploadId、分片索引、状态存储和清理规则达成严格一致。Fetch 是工具，逻辑得你来编排。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
