大文件分片上传需借助 blob.slice() 切片、fetch 逐个上传并由服务端合并；关键包括切片大小（2–5 mb）、顺序/并发控制、断点续传、元信息携带（文件id、分片序号等）、错误重试及最终合并请求。
大文件分片上传不是靠 Fetch 单次请求完成的，而是把文件切块、逐个上传、服务端再合并。Fetch 本身不提供分片能力，但可以配合 Blob.slice() 和手动管理请求序列来实现。
1. 文件切片：用 Blob.slice() 拆分二进制数据
浏览器中 File 对象继承自 Blob，可用 slice(start, end, type) 提取指定字节范围的子 Blob：
- 建议每片 2–5 MB（太小增加 HTTP 开销，太大影响失败重传成本）
- 起始位置按字节计算，例如第 3 片：start = 2 * 4 * 1024 * 1024，end = 3 * 4 * 1024 * 1024
- 保持 MIME 类型一致，如
file.type或显式传"application/octet-stream"
2. 分片上传控制：顺序/并发 + 断点续传
Fetch 是 Promise，天然支持链式或并行处理，但需注意：
- 顺序上传：用
for...of+await，适合弱网或服务端不支持乱序写入 - 并发上传：用
Promise.allSettled()控制最大并发数（如 3~5 个），提升速度但需服务端支持独立分片标识 - 断点续传：上传前先发请求查已上传的分片编号（如
/upload/status?fileId=xxx），跳过已成功部分
3. 请求携带关键元信息
每个分片请求至少要附带以下字段，让服务端能正确归类和拼接：
- 文件唯一标识（如 hash 或客户端生成的 UUID），避免同名文件冲突
-
分片序号（
chunkIndex）和 总片数（totalChunks） - 当前分片大小与偏移量（可选，用于校验或服务端预分配空间）
- 推荐放在请求 body 的 FormData 中，或用 JSON body + 显式
Content-Type: application/json
4. 错误处理与重试策略
网络不稳定时分片容易失败，不能简单 throw：
- 对单个 fetch 加
catch，记录失败分片编号，不中断整体流程 - 设置重试次数（如 2~3 次），每次间隔指数退避（1s → 2s → 4s）
- 最终失败后汇总未完成列表，提示用户“第 X、Y 片上传失败，是否重试？”
不复杂但容易忽略的是服务端必须提供分片校验（如 MD5/SHA-256）和合并触发接口。前端上传完所有分片后，需再发一个合并请求（如 POST /upload/merge），由服务端校验完整性并组装成完整文件。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
