大文件上传需切片并发处理以提升成功率和体验。通过Blob.slice()按字节切分、控制3–6路并发、服务端支持分片存储与合并，实现断点续传和高效上传。
大文件上传卡顿、失败率高、无法断点续传？核心在于避免单次请求承载过大体积。用 Blob 切片 + 分片并发上传，能显著提升成功率、速度和用户体验。
一、为什么必须切片？
浏览器对单次 HTTP 请求体大小没有硬性上限，但实际中受服务端配置（如 Nginx 的 client_max_body_size）、内存占用、网络波动和超时限制影响极大。一个 2GB 文件若直接上传，极易触发超时、OOM 或被中间代理截断。切片后，每个请求仅处理几 MB 数据，可控性强，还能单独重传失败分片，实现断点续传。
二、如何用 Blob.slice() 安全切片？
Blob 原生支持 slice() 方法，返回新的 Blob 对象，不拷贝原始数据，内存友好：
- 按字节偏移切分：例如 file.slice(start, end)，start 和 end 是 number 类型，单位为字节
- 推荐固定分片大小（如 5MB），最后一片自动取余；避免按“行”或“字符”切，防止破坏二进制完整性
- 注意：切片顺序不影响内容，但服务端需按序号拼接，前端必须记录每片的 index 和总片数 totalChunks
三、并发上传与请求控制
并发能压榨带宽，但盲目开太多会挤占连接、触发限流或拖慢整体响应。建议：
- 控制并发数（如 3–6 个），用 PromisePool 或简单的 for + await + 限流队列实现
- 每片上传携带唯一标识（如文件 hash + index），便于服务端去重和校验
- 上传前可先发预检请求（如 POST /upload/precheck）确认是否已存在该分片，跳过重复上传
- 监听 upload.onprogress 计算整体进度，而非仅单片进度
四、服务端配合要点
前端切片只是第一步，服务端需支持：
- 接收分片并临时存储（如存入本地磁盘或对象存储的临时目录），命名含 fileId_index
- 提供合并接口（如 POST /upload/merge），校验所有分片 MD5/SHA1 后拼接成完整文件
- 支持查询已上传分片列表（用于断点续传），返回已存在 index 数组，前端只补传缺失片
- 设置合理超时（分片请求可设 30–60s，合并操作视文件大小放宽）
不复杂但容易忽略：前后端时间戳、hash 算法、编码方式（如 index 用字符串还是数字）需严格对齐，否则合并失败无提示。
