17370845950

大文件上传需分片处理以保障稳定性与用户体验。核心是生成文件指纹实现秒传，异步分片上传并控制并发，服务端支持分片校验、临时存储与按序合并，配合断点续传、进度反馈及合并状态轮询等优化。

JavaScript 文件上传本身不难，但大文件（比如 500MB 以上）直接上传容易失败：浏览器卡顿、请求超时、服务端拒绝、网络中断后无法续传。核心解法是分片上传——把大文件切小块，逐个上传，再在服务端合并。关键不在“怎么切”，而在于如何保证分片顺序、去重、断点续传和并发控制。

1. 前端分片与计算文件唯一标识

分片前先生成文件指纹（如 MD5 或 SparkMD5），用于判断是否已上传过相同文件（秒传基础）。注意：全量计算大文件 MD5 会阻塞主线程，必须用 FileReader + Web Worker 或分块读取方式异步计算。

• 使用 file.slice(start, end) 切片（注意不是 Array.prototype.slice）
• 推荐每片 2–5 MB（太小增加 HTTP 开销，太大降低并发灵活性）
• 每片带上参数：chunkIndex、totalChunks、fileHash、fileName

2. 并发上传 + 断点续传逻辑

不能一次性发所有请求，需控制并发数（如 3–5 个），同时记录已成功上传的分片索引。上传前先向服务端查询哪些分片已存在（通过 fileHash + chunkIndex），跳过已传部分。

• 用 Promise.allSettled() 管理并发批次，避免一个失败导致整批中断
• 每个分片请求带 onprogress 监听上传进度，汇总为整体进度
• 网络失败时保存当前已成功分片列表，恢复时只重传失败或未开始的片

3. 服务端配合要点（前端需了解）

前端分片只是第一步，服务端必须支持：接收分片、校验分片完整性、临时存储、按序合并、清理过期碎片。常见做法：

• 分片以 {fileHash}/{chunkIndex} 路径存入对象存储（如 OSS、S3）或本地临时目录
• 合并请求触发后，服务端按 chunkIndex 升序拉取并拼接二进制流
• 加超时清理任务（例如 24 小时未完成合并的碎片自动删除）

4. 用户体验优化细节

真实项目中，用户感知比技术实现更重要：

• 上传前显示预估时间（基于网速探测 + 分片大小粗略计算）
• 暂停/恢复按钮需真正暂停所有进行中请求（用 AbortController）
• 支持拖拽多文件 + 按文件类型/大小自动分流（小文件直传，大文件走分片）
• 上传完成不直接提示“成功”，而是轮询服务端合并状态，避免“已上传”但实际未合并