1. 项目概述为什么大文件上传需要断点续传做前端的兄弟特别是搞过文件上传的应该都遇到过这种场景用户上传一个几个G的视频或者设计源文件进度条走到99%了网络一抖或者用户手一滑关了页面得一切从头再来。用户骂娘你心里也憋屈。这就是“大文件上传”这个经典需求里最让人头疼的“最后一公里”问题。断点续传就是为了解决这个痛点而生的。简单说断点续传就是把一个大文件切成很多小块然后一块一块地上传。服务器会记录哪些块已经传好了哪些还没传。这样即使中途断了下次再传的时候只需要接着传那些没传完的块就行而不是傻乎乎地从头再来。这听起来像是后端该操心的事但前端在这里面扮演的角色至关重要从文件分片、计算唯一标识到控制并发、管理上传状态每一步都离不开前端的精细操作。最近社区里讨论比较多的“前端使用worker上传大文件”其实就是把分片计算、哈希生成这些CPU密集型任务放到Web Worker里避免阻塞主线程导致页面卡顿让上传体验更丝滑。接下来我就结合自己趟过的坑把这套机制从设计思路到代码实操掰开揉碎了讲清楚。2. 核心思路与架构设计2.1 断点续传的核心逻辑拆解断点续传不是魔法它的核心逻辑建立在几个关键步骤上理解了这个流程后面的实现就是按图索骥。首先文件分片。这是所有操作的起点。你不能把整个几GB的文件一次性扔给服务器那样超时、内存溢出是家常便饭。常见的分片大小是1MB到5MB具体看业务和网络环境。分片后每个片就是一个独立的HTTP请求通常是PUT或POST。其次唯一标识。服务器怎么知道这些片是属于同一个文件的又怎么知道哪些片传过了这就需要前端为整个文件生成一个唯一标识通常使用文件的哈希值如MD5、SHA-256。注意这里计算全文件的哈希在大文件时是个耗时操作这就是为什么需要Web Worker。然后进度追踪与状态管理。前端需要维护一个状态记录每一个分片的上传状态未开始、上传中、已完成、失败。这个状态需要持久化比如存到localStorage或IndexedDB里这样页面刷新后还能恢复。当点击“继续上传”时前端先向服务器询问该文件已上传的分片列表然后只上传状态为“未开始”或“失败”的片。最后服务端合并。所有分片上传完毕后前端通知服务端“我的片都齐了请合并成一个完整的文件。”服务端按照分片的索引顺序将这些片拼接起来完成整个文件的存储。2.2 前端架构选型主线程 vs. Web Worker这是当前的一个热点。传统做法是把分片、计算哈希这些活放在主线程做。对于几百兆的文件可能还行但一旦上了GB级别计算一个MD5哈希可能让页面“冻结”好几秒用户体验极差。Web Worker方案的优势就在于将重型计算任务移出主线程。你可以创建一个Worker把File对象传给它注意是传递引用实际数据是零拷贝的性能很好让它在后台默默地进行分片和哈希计算。计算完成后将分片数据和文件哈希回传给主线程。主线程只负责轻量的任务调度、网络请求和UI更新。这样用户在上传时依然可以流畅地操作页面。为什么不直接用现成的库像resumable.js、plupload这样的库确实提供了封装。但自己实现一遍你才能真正理解其中的细节和坑比如如何优雅地处理Worker错误、如何设计分片重试机制、如何实现暂停/恢复。这对于应对复杂多变的业务需求至关重要。3. 关键实现细节与实操要点3.1 文件分片与哈希生成这是整个流程的技术基石细节决定成败。// 在主线程中启动Worker const worker new Worker(./file-processor.worker.js); worker.postMessage({ file: file, chunkSize: 2 * 1024 * 1024 }); // 2MB一片 worker.onmessage (event) { const { fileHash, chunks } event.data; // 拿到文件哈希和分片数组可以开始上传了 this.startUpload(fileHash, chunks); };在Worker脚本 (file-processor.worker.js) 中// 使用 SparkMD5 库计算文件哈希需在Worker中引入 self.importScripts(spark-md5.min.js); onmessage async (e) { const { file, chunkSize } e.data; const spark new SparkMD5.ArrayBuffer(); const chunks []; const totalChunks Math.ceil(file.size / chunkSize); for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize, file.size); const chunkBlob file.slice(start, end); // 关键APIFile.slice chunks.push({ index: i, blob: chunkBlob, start, end }); // 增量更新哈希 spark.append(await chunkBlob.arrayBuffer()); } const fileHash spark.end(); // 得到最终的文件哈希 // 将结果传回主线程 postMessage({ fileHash, chunks }); };注意File.slice()方法是性能关键它并不会真的复制文件数据而是创建一个指向原文件某部分数据的“视图”Blob所以分片操作本身很快。计算哈希才是CPU瓶颈。实操心得1哈希算法的选择MD5速度较快但存在理论上的碰撞可能。对于绝大多数非安全敏感的文件去重和标识场景MD5完全够用。如果追求更高的唯一性可以选择SHA-256但计算时间会显著增加。我的经验是先问业务方这个文件的唯一标识是用来做什么的如果只是用于断点续传和秒传检查服务器是否已有相同文件MD5足矣。如果需要防篡改或更高安全级别再考虑SHA系列。3.2 服务端接口设计与交互流程前端需要和后端约定好一套清晰的API协议。一个典型的流程需要三个核心接口检查接口 (/api/upload/check)目的上传前先“问问”服务器这个文件传过没传了哪些片了请求携带fileHash文件唯一标识、fileName、totalSize。响应{ shouldUpload: true, // 是否需要上传false表示文件已存在秒传成功 uploadedChunks: [0, 1, 3, 5] // 服务器已存在的分片索引列表 }分片上传接口 (/api/upload/chunk)目的上传单个分片。请求使用FormData包含fileHash、chunkIndex分片序号、chunk分片Blob数据、totalChunks总分片数。响应简单返回成功状态即可。这里有个关键点服务端存储分片时命名规则要统一例如${fileHash}_${chunkIndex}.part方便管理和查找。合并接口 (/api/upload/merge)目的通知服务器所有分片已上传完毕请合并。请求fileHash、fileName、totalChunks。响应合并成功后的文件访问路径。实操心得2接口的幂等性/api/upload/chunk这个接口必须设计成幂等的。也就是说同一个fileHash和chunkIndex的请求无论重复发送多少次结果都应该一样即该分片已存在。这是实现可靠重试的基础。前端在上传失败后可以放心地重试某个分片而不用担心服务端会重复存储或报错。3.3 前端上传控制与状态管理有了分片和接口前端就需要一个“大脑”来调度这一切。这个大脑需要处理并发控制同时发起多少个上传请求太多会挤爆浏览器和服务器太少则速度慢。通常动态设置比如3-5个。任务队列将待上传的分片放入队列由并发控制器按顺序取出执行。状态持久化将fileHash、chunks状态每个片的上传进度、状态存到localStorage。页面刷新后能读取状态并重新向服务器check恢复上传列表。暂停/继续暂停时取消所有正在进行的XMLHttpRequest或fetch请求并清空任务队列。继续时重新check并开始上传。class UploadManager { constructor(fileHash, chunks) { this.fileHash fileHash; this.chunks chunks; // 包含blob和状态的对象数组 this.maxConcurrent 3; // 最大并发数 this.currentConcurrent 0; this.queue []; this.isPaused false; this.loadStateFromLocalStorage(); } async start() { // 1. 先检查服务器状态 const { uploadedChunks } await this.checkServer(); // 2. 更新本地分片状态标记已上传的为完成 this.markUploadedChunks(uploadedChunks); // 3. 将需要上传的分片加入队列 this.queue this.chunks.filter(chunk chunk.status ! completed); // 4. 启动队列消费 this.consumeQueue(); } pause() { this.isPaused true; // 取消所有进行中的请求需要保存xhr引用 this.activeRequests.forEach(xhr xhr.abort()); this.activeRequests.clear(); } resume() { this.isPaused false; this.start(); // 重新走检查流程 } async consumeQueue() { while (this.queue.length 0 this.currentConcurrent this.maxConcurrent !this.isPaused) { this.currentConcurrent; const chunk this.queue.shift(); this.uploadChunk(chunk).finally(() { this.currentConcurrent--; this.consumeQueue(); // 递归调用继续处理队列 }); } } async uploadChunk(chunk) { const formData new FormData(); formData.append(fileHash, this.fileHash); formData.append(chunkIndex, chunk.index); formData.append(chunk, chunk.blob); formData.append(totalChunks, this.chunks.length); try { await axios.post(/api/upload/chunk, formData, { onUploadProgress: (progressEvent) { // 更新该分片的进度用于计算总进度 chunk.progress Math.round((progressEvent.loaded * 100) / progressEvent.total); this.updateGlobalProgress(); } }); chunk.status completed; this.saveStateToLocalStorage(); // 如果所有分片完成调用合并接口 if (this.allChunksDone()) { await this.mergeFiles(); } } catch (error) { chunk.status error; // 可选将失败的分片重新加入队列尾部进行重试 if (chunk.retryCount 3) { chunk.retryCount; this.queue.push(chunk); } } } }4. 完整实现流程与代码解析4.1 从零搭建一个带Worker的断点续传组件让我们把上面的模块组装起来创建一个可复用的Vue/React组件这里以概念性代码为例。第一步创建Web Worker文件单独创建public/upload.worker.js内容就是前面提到的分片和计算哈希的逻辑记得引入SparkMD5库。第二步组件初始化与文件选择// 在组件中 handleFileSelect async (event) { const file event.target.files[0]; if (!file) return; // 显示“计算中”状态提升体验 this.setState({ status: processing }); // 启动Worker const worker new Worker(./upload.worker.js); worker.postMessage({ file: file, chunkSize: 2 * 1024 * 1024 }); worker.onmessage (e) { const { fileHash, chunks } e.data; worker.terminate(); // 计算完成关闭Worker this.setState({ fileHash, chunks: chunks.map(c ({...c, status: pending, progress: 0})), status: ready }); // 初始化上传管理器 this.uploadManager new UploadManager(fileHash, this.state.chunks); // 可以自动开始或等待用户点击 // this.uploadManager.start(); }; worker.onerror (error) { console.error(Worker error:, error); this.setState({ status: error, errorMsg: 文件处理失败 }); }; };第三步整合上传管理器并渲染进度在组件中将UploadManager的实例与组件状态绑定。管理器在上传每个分片时会更新分片状态和进度。组件通过监听这些状态的变化来渲染一个可视化的上传进度条并展示每个分片的状态等待、上传中、成功、失败。第四步实现暂停/继续按钮按钮的点击事件直接调用uploadManager.pause()和uploadManager.resume()。暂停时UI进度条停止更新继续时进度条从上次中断的地方继续前进。4.2 服务端Node.js Koa简易实现示例前端玩得转后端也得接得住。这里给一个基于Node.js Koa框架的极简示例展示核心逻辑。// 服务端检查接口 router.post(/upload/check, async (ctx) { const { fileHash, fileName } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const filePath path.resolve(UPLOAD_DIR, ${fileHash}-${fileName}); // 1. 文件已存在秒传 if (fse.existsSync(filePath)) { ctx.body { shouldUpload: false, uploadedChunks: [] }; return; } // 2. 读取已上传的分片信息 let uploadedChunks []; if (fse.existsSync(chunkDir)) { uploadedChunks await fse.readdir(chunkDir); // 假设分片文件名为 0.part, 1.part... uploadedChunks uploadedChunks.map(name parseInt(name.split(.)[0])); } ctx.body { shouldUpload: true, uploadedChunks }; }); // 服务端分片上传接口 router.post(/upload/chunk, async (ctx) { const { fileHash, chunkIndex } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const file ctx.request.files.chunk; // 使用koa-body中间件处理文件 // 确保分片目录存在 await fse.ensureDir(chunkDir); // 移动分片文件到目录文件名使用索引 const chunkPath path.resolve(chunkDir, ${chunkIndex}.part); // 使用move实现因为文件已在临时目录 await fse.move(file.filepath, chunkPath, { overwrite: true }); // 幂等性关键覆盖 ctx.body { code: 0, msg: 分片上传成功 }; }); // 服务端合并接口 router.post(/upload/merge, async (ctx) { const { fileHash, fileName, totalChunks } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const filePath path.resolve(UPLOAD_DIR, ${fileHash}-${fileName}); // 1. 检查所有分片是否都存在 const chunkPaths await fse.readdir(chunkDir); if (chunkPaths.length ! totalChunks) { ctx.status 400; ctx.body { msg: 分片数量不完整 }; return; } // 2. 按索引排序后合并 chunkPaths.sort((a, b) parseInt(a) - parseInt(b)); const writeStream fse.createWriteStream(filePath); for (const chunkName of chunkPaths) { const chunkPath path.resolve(chunkDir, chunkName); const chunkBuffer await fse.readFile(chunkPath); writeStream.write(chunkBuffer); await fse.unlink(chunkPath); // 可选项合并后删除分片 } writeStream.end(); // 3. 清理空的分片目录 await fse.rmdir(chunkDir); ctx.body { code: 0, msg: 合并成功, url: /uploads/${fileHash}-${fileName} }; });5. 常见问题排查与性能优化5.1 典型问题与解决方案在实际开发中你会遇到各种各样的问题。下面这个表格整理了我踩过的一些坑和解决办法问题现象可能原因排查步骤与解决方案文件哈希计算时间过长页面卡死主线程进行大文件哈希计算。使用Web Worker将计算任务移出主线程。检查Worker脚本是否被正确加载并确保spark-md5库在Worker作用域内可用。分片上传到90%后失败无法续传1. 服务端未正确记录已上传分片。2. 前端状态丢失如刷新页面。1. 检查服务端/check接口确认其返回的uploadedChunks列表是否准确。确保分片存储的命名规则与检查逻辑一致。2. 前端必须将fileHash和分片状态持久化到localStorage。刷新后先用fileHash去服务器check再恢复本地状态。并发上传时部分分片总是失败1. 浏览器HTTP并发连接数限制同域名通常6个。2. 服务器端处理能力不足或超时。1. 降低前端并发数例如从5降到3。可以动态调整根据上传成功率自适应。2. 增加服务端分片上传接口的超时时间。优化服务端处理逻辑比如将分片文件写入改为流式操作避免内存占用过高。合并文件后文件损坏或无法打开分片顺序在合并时错乱。确保服务端存储分片时文件名包含索引如0.part。在合并前必须按索引数字顺序对分片文件进行排序。fs.readdir的结果顺序是不确定的。秒传功能失效文件哈希值计算不一致。检查前后端哈希算法是否一致都使用MD5。确保前端在计算哈希时分片的顺序和大小完全一致。如果文件内容相同但元信息如修改时间不同应只对文件二进制内容计算哈希。5.2 高级优化技巧当基本功能跑通后可以考虑下面这些优化点让体验更专业动态分片大小固定分片大小如2MB可能不是最优的。对于网络条件好的用户可以尝试增大分片如5MB以减少请求数对于网络不稳定的可以减小分片如512KB以提升容错性。可以在上传前做一个简单的网络测速来动态决定。增量哈希计算与秒传优化在Worker中计算文件哈希时可以同时将每个分片的哈希也计算出来。在上传前check时不仅发送文件总哈希还可以发送分片哈希列表。这样即使服务器没有完整的文件但可能有部分相同的分片来自其他用户可以实现“增量秒传”进一步减少数据传输量。上传暂停/恢复的精细化控制不仅仅是取消网络请求。在暂停时应该记录每个正在上传分片的已传输字节数通过XMLHttpRequest的onprogress事件。恢复时可以尝试为这些分片设置HTTP头Range: bytesxxx-来进行断点续传这需要服务端支持避免整个分片重传。错误重试与退避策略网络请求失败后不要立即重试。实现一个简单的指数退避策略第一次失败等1秒后重试第二次失败等2秒第三次等4秒……并设置最大重试次数。这能有效避免在服务器临时故障时加剧其压力。内存管理虽然File.slice()创建的是Blob视图但如果你同时将大量分片Blob保存在内存数组中比如在chunks对象里对于超大文件仍可能导致内存压力。可以考虑“流式”处理计算完一个分片的哈希并放入队列后是否可以考虑释放对该分片Blob的引用这需要仔细设计数据流但能提升超大文件上传的稳定性。最后一点个人体会断点续传是一个看似简单、实则细节繁多的功能。它完美地结合了前端性能优化、网络编程、状态管理和用户体验设计。自己动手实现一遍你会对前端如何处理二进制数据、如何与Worker通信、如何设计有状态的任务调度有更深的理解。这套模式不仅用于文件上传其思想分治、状态持久化、异步队列可以迁移到很多其他需要处理大量数据或长任务的场景中。
1. 项目概述为什么大文件上传需要断点续传做前端的兄弟特别是搞过文件上传的应该都遇到过这种场景用户上传一个几个G的视频或者设计源文件进度条走到99%了网络一抖或者用户手一滑关了页面得一切从头再来。用户骂娘你心里也憋屈。这就是“大文件上传”这个经典需求里最让人头疼的“最后一公里”问题。断点续传就是为了解决这个痛点而生的。简单说断点续传就是把一个大文件切成很多小块然后一块一块地上传。服务器会记录哪些块已经传好了哪些还没传。这样即使中途断了下次再传的时候只需要接着传那些没传完的块就行而不是傻乎乎地从头再来。这听起来像是后端该操心的事但前端在这里面扮演的角色至关重要从文件分片、计算唯一标识到控制并发、管理上传状态每一步都离不开前端的精细操作。最近社区里讨论比较多的“前端使用worker上传大文件”其实就是把分片计算、哈希生成这些CPU密集型任务放到Web Worker里避免阻塞主线程导致页面卡顿让上传体验更丝滑。接下来我就结合自己趟过的坑把这套机制从设计思路到代码实操掰开揉碎了讲清楚。2. 核心思路与架构设计2.1 断点续传的核心逻辑拆解断点续传不是魔法它的核心逻辑建立在几个关键步骤上理解了这个流程后面的实现就是按图索骥。首先文件分片。这是所有操作的起点。你不能把整个几GB的文件一次性扔给服务器那样超时、内存溢出是家常便饭。常见的分片大小是1MB到5MB具体看业务和网络环境。分片后每个片就是一个独立的HTTP请求通常是PUT或POST。其次唯一标识。服务器怎么知道这些片是属于同一个文件的又怎么知道哪些片传过了这就需要前端为整个文件生成一个唯一标识通常使用文件的哈希值如MD5、SHA-256。注意这里计算全文件的哈希在大文件时是个耗时操作这就是为什么需要Web Worker。然后进度追踪与状态管理。前端需要维护一个状态记录每一个分片的上传状态未开始、上传中、已完成、失败。这个状态需要持久化比如存到localStorage或IndexedDB里这样页面刷新后还能恢复。当点击“继续上传”时前端先向服务器询问该文件已上传的分片列表然后只上传状态为“未开始”或“失败”的片。最后服务端合并。所有分片上传完毕后前端通知服务端“我的片都齐了请合并成一个完整的文件。”服务端按照分片的索引顺序将这些片拼接起来完成整个文件的存储。2.2 前端架构选型主线程 vs. Web Worker这是当前的一个热点。传统做法是把分片、计算哈希这些活放在主线程做。对于几百兆的文件可能还行但一旦上了GB级别计算一个MD5哈希可能让页面“冻结”好几秒用户体验极差。Web Worker方案的优势就在于将重型计算任务移出主线程。你可以创建一个Worker把File对象传给它注意是传递引用实际数据是零拷贝的性能很好让它在后台默默地进行分片和哈希计算。计算完成后将分片数据和文件哈希回传给主线程。主线程只负责轻量的任务调度、网络请求和UI更新。这样用户在上传时依然可以流畅地操作页面。为什么不直接用现成的库像resumable.js、plupload这样的库确实提供了封装。但自己实现一遍你才能真正理解其中的细节和坑比如如何优雅地处理Worker错误、如何设计分片重试机制、如何实现暂停/恢复。这对于应对复杂多变的业务需求至关重要。3. 关键实现细节与实操要点3.1 文件分片与哈希生成这是整个流程的技术基石细节决定成败。// 在主线程中启动Worker const worker new Worker(./file-processor.worker.js); worker.postMessage({ file: file, chunkSize: 2 * 1024 * 1024 }); // 2MB一片 worker.onmessage (event) { const { fileHash, chunks } event.data; // 拿到文件哈希和分片数组可以开始上传了 this.startUpload(fileHash, chunks); };在Worker脚本 (file-processor.worker.js) 中// 使用 SparkMD5 库计算文件哈希需在Worker中引入 self.importScripts(spark-md5.min.js); onmessage async (e) { const { file, chunkSize } e.data; const spark new SparkMD5.ArrayBuffer(); const chunks []; const totalChunks Math.ceil(file.size / chunkSize); for (let i 0; i totalChunks; i) { const start i * chunkSize; const end Math.min(start chunkSize, file.size); const chunkBlob file.slice(start, end); // 关键APIFile.slice chunks.push({ index: i, blob: chunkBlob, start, end }); // 增量更新哈希 spark.append(await chunkBlob.arrayBuffer()); } const fileHash spark.end(); // 得到最终的文件哈希 // 将结果传回主线程 postMessage({ fileHash, chunks }); };注意File.slice()方法是性能关键它并不会真的复制文件数据而是创建一个指向原文件某部分数据的“视图”Blob所以分片操作本身很快。计算哈希才是CPU瓶颈。实操心得1哈希算法的选择MD5速度较快但存在理论上的碰撞可能。对于绝大多数非安全敏感的文件去重和标识场景MD5完全够用。如果追求更高的唯一性可以选择SHA-256但计算时间会显著增加。我的经验是先问业务方这个文件的唯一标识是用来做什么的如果只是用于断点续传和秒传检查服务器是否已有相同文件MD5足矣。如果需要防篡改或更高安全级别再考虑SHA系列。3.2 服务端接口设计与交互流程前端需要和后端约定好一套清晰的API协议。一个典型的流程需要三个核心接口检查接口 (/api/upload/check)目的上传前先“问问”服务器这个文件传过没传了哪些片了请求携带fileHash文件唯一标识、fileName、totalSize。响应{ shouldUpload: true, // 是否需要上传false表示文件已存在秒传成功 uploadedChunks: [0, 1, 3, 5] // 服务器已存在的分片索引列表 }分片上传接口 (/api/upload/chunk)目的上传单个分片。请求使用FormData包含fileHash、chunkIndex分片序号、chunk分片Blob数据、totalChunks总分片数。响应简单返回成功状态即可。这里有个关键点服务端存储分片时命名规则要统一例如${fileHash}_${chunkIndex}.part方便管理和查找。合并接口 (/api/upload/merge)目的通知服务器所有分片已上传完毕请合并。请求fileHash、fileName、totalChunks。响应合并成功后的文件访问路径。实操心得2接口的幂等性/api/upload/chunk这个接口必须设计成幂等的。也就是说同一个fileHash和chunkIndex的请求无论重复发送多少次结果都应该一样即该分片已存在。这是实现可靠重试的基础。前端在上传失败后可以放心地重试某个分片而不用担心服务端会重复存储或报错。3.3 前端上传控制与状态管理有了分片和接口前端就需要一个“大脑”来调度这一切。这个大脑需要处理并发控制同时发起多少个上传请求太多会挤爆浏览器和服务器太少则速度慢。通常动态设置比如3-5个。任务队列将待上传的分片放入队列由并发控制器按顺序取出执行。状态持久化将fileHash、chunks状态每个片的上传进度、状态存到localStorage。页面刷新后能读取状态并重新向服务器check恢复上传列表。暂停/继续暂停时取消所有正在进行的XMLHttpRequest或fetch请求并清空任务队列。继续时重新check并开始上传。class UploadManager { constructor(fileHash, chunks) { this.fileHash fileHash; this.chunks chunks; // 包含blob和状态的对象数组 this.maxConcurrent 3; // 最大并发数 this.currentConcurrent 0; this.queue []; this.isPaused false; this.loadStateFromLocalStorage(); } async start() { // 1. 先检查服务器状态 const { uploadedChunks } await this.checkServer(); // 2. 更新本地分片状态标记已上传的为完成 this.markUploadedChunks(uploadedChunks); // 3. 将需要上传的分片加入队列 this.queue this.chunks.filter(chunk chunk.status ! completed); // 4. 启动队列消费 this.consumeQueue(); } pause() { this.isPaused true; // 取消所有进行中的请求需要保存xhr引用 this.activeRequests.forEach(xhr xhr.abort()); this.activeRequests.clear(); } resume() { this.isPaused false; this.start(); // 重新走检查流程 } async consumeQueue() { while (this.queue.length 0 this.currentConcurrent this.maxConcurrent !this.isPaused) { this.currentConcurrent; const chunk this.queue.shift(); this.uploadChunk(chunk).finally(() { this.currentConcurrent--; this.consumeQueue(); // 递归调用继续处理队列 }); } } async uploadChunk(chunk) { const formData new FormData(); formData.append(fileHash, this.fileHash); formData.append(chunkIndex, chunk.index); formData.append(chunk, chunk.blob); formData.append(totalChunks, this.chunks.length); try { await axios.post(/api/upload/chunk, formData, { onUploadProgress: (progressEvent) { // 更新该分片的进度用于计算总进度 chunk.progress Math.round((progressEvent.loaded * 100) / progressEvent.total); this.updateGlobalProgress(); } }); chunk.status completed; this.saveStateToLocalStorage(); // 如果所有分片完成调用合并接口 if (this.allChunksDone()) { await this.mergeFiles(); } } catch (error) { chunk.status error; // 可选将失败的分片重新加入队列尾部进行重试 if (chunk.retryCount 3) { chunk.retryCount; this.queue.push(chunk); } } } }4. 完整实现流程与代码解析4.1 从零搭建一个带Worker的断点续传组件让我们把上面的模块组装起来创建一个可复用的Vue/React组件这里以概念性代码为例。第一步创建Web Worker文件单独创建public/upload.worker.js内容就是前面提到的分片和计算哈希的逻辑记得引入SparkMD5库。第二步组件初始化与文件选择// 在组件中 handleFileSelect async (event) { const file event.target.files[0]; if (!file) return; // 显示“计算中”状态提升体验 this.setState({ status: processing }); // 启动Worker const worker new Worker(./upload.worker.js); worker.postMessage({ file: file, chunkSize: 2 * 1024 * 1024 }); worker.onmessage (e) { const { fileHash, chunks } e.data; worker.terminate(); // 计算完成关闭Worker this.setState({ fileHash, chunks: chunks.map(c ({...c, status: pending, progress: 0})), status: ready }); // 初始化上传管理器 this.uploadManager new UploadManager(fileHash, this.state.chunks); // 可以自动开始或等待用户点击 // this.uploadManager.start(); }; worker.onerror (error) { console.error(Worker error:, error); this.setState({ status: error, errorMsg: 文件处理失败 }); }; };第三步整合上传管理器并渲染进度在组件中将UploadManager的实例与组件状态绑定。管理器在上传每个分片时会更新分片状态和进度。组件通过监听这些状态的变化来渲染一个可视化的上传进度条并展示每个分片的状态等待、上传中、成功、失败。第四步实现暂停/继续按钮按钮的点击事件直接调用uploadManager.pause()和uploadManager.resume()。暂停时UI进度条停止更新继续时进度条从上次中断的地方继续前进。4.2 服务端Node.js Koa简易实现示例前端玩得转后端也得接得住。这里给一个基于Node.js Koa框架的极简示例展示核心逻辑。// 服务端检查接口 router.post(/upload/check, async (ctx) { const { fileHash, fileName } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const filePath path.resolve(UPLOAD_DIR, ${fileHash}-${fileName}); // 1. 文件已存在秒传 if (fse.existsSync(filePath)) { ctx.body { shouldUpload: false, uploadedChunks: [] }; return; } // 2. 读取已上传的分片信息 let uploadedChunks []; if (fse.existsSync(chunkDir)) { uploadedChunks await fse.readdir(chunkDir); // 假设分片文件名为 0.part, 1.part... uploadedChunks uploadedChunks.map(name parseInt(name.split(.)[0])); } ctx.body { shouldUpload: true, uploadedChunks }; }); // 服务端分片上传接口 router.post(/upload/chunk, async (ctx) { const { fileHash, chunkIndex } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const file ctx.request.files.chunk; // 使用koa-body中间件处理文件 // 确保分片目录存在 await fse.ensureDir(chunkDir); // 移动分片文件到目录文件名使用索引 const chunkPath path.resolve(chunkDir, ${chunkIndex}.part); // 使用move实现因为文件已在临时目录 await fse.move(file.filepath, chunkPath, { overwrite: true }); // 幂等性关键覆盖 ctx.body { code: 0, msg: 分片上传成功 }; }); // 服务端合并接口 router.post(/upload/merge, async (ctx) { const { fileHash, fileName, totalChunks } ctx.request.body; const chunkDir path.resolve(UPLOAD_DIR, fileHash); const filePath path.resolve(UPLOAD_DIR, ${fileHash}-${fileName}); // 1. 检查所有分片是否都存在 const chunkPaths await fse.readdir(chunkDir); if (chunkPaths.length ! totalChunks) { ctx.status 400; ctx.body { msg: 分片数量不完整 }; return; } // 2. 按索引排序后合并 chunkPaths.sort((a, b) parseInt(a) - parseInt(b)); const writeStream fse.createWriteStream(filePath); for (const chunkName of chunkPaths) { const chunkPath path.resolve(chunkDir, chunkName); const chunkBuffer await fse.readFile(chunkPath); writeStream.write(chunkBuffer); await fse.unlink(chunkPath); // 可选项合并后删除分片 } writeStream.end(); // 3. 清理空的分片目录 await fse.rmdir(chunkDir); ctx.body { code: 0, msg: 合并成功, url: /uploads/${fileHash}-${fileName} }; });5. 常见问题排查与性能优化5.1 典型问题与解决方案在实际开发中你会遇到各种各样的问题。下面这个表格整理了我踩过的一些坑和解决办法问题现象可能原因排查步骤与解决方案文件哈希计算时间过长页面卡死主线程进行大文件哈希计算。使用Web Worker将计算任务移出主线程。检查Worker脚本是否被正确加载并确保spark-md5库在Worker作用域内可用。分片上传到90%后失败无法续传1. 服务端未正确记录已上传分片。2. 前端状态丢失如刷新页面。1. 检查服务端/check接口确认其返回的uploadedChunks列表是否准确。确保分片存储的命名规则与检查逻辑一致。2. 前端必须将fileHash和分片状态持久化到localStorage。刷新后先用fileHash去服务器check再恢复本地状态。并发上传时部分分片总是失败1. 浏览器HTTP并发连接数限制同域名通常6个。2. 服务器端处理能力不足或超时。1. 降低前端并发数例如从5降到3。可以动态调整根据上传成功率自适应。2. 增加服务端分片上传接口的超时时间。优化服务端处理逻辑比如将分片文件写入改为流式操作避免内存占用过高。合并文件后文件损坏或无法打开分片顺序在合并时错乱。确保服务端存储分片时文件名包含索引如0.part。在合并前必须按索引数字顺序对分片文件进行排序。fs.readdir的结果顺序是不确定的。秒传功能失效文件哈希值计算不一致。检查前后端哈希算法是否一致都使用MD5。确保前端在计算哈希时分片的顺序和大小完全一致。如果文件内容相同但元信息如修改时间不同应只对文件二进制内容计算哈希。5.2 高级优化技巧当基本功能跑通后可以考虑下面这些优化点让体验更专业动态分片大小固定分片大小如2MB可能不是最优的。对于网络条件好的用户可以尝试增大分片如5MB以减少请求数对于网络不稳定的可以减小分片如512KB以提升容错性。可以在上传前做一个简单的网络测速来动态决定。增量哈希计算与秒传优化在Worker中计算文件哈希时可以同时将每个分片的哈希也计算出来。在上传前check时不仅发送文件总哈希还可以发送分片哈希列表。这样即使服务器没有完整的文件但可能有部分相同的分片来自其他用户可以实现“增量秒传”进一步减少数据传输量。上传暂停/恢复的精细化控制不仅仅是取消网络请求。在暂停时应该记录每个正在上传分片的已传输字节数通过XMLHttpRequest的onprogress事件。恢复时可以尝试为这些分片设置HTTP头Range: bytesxxx-来进行断点续传这需要服务端支持避免整个分片重传。错误重试与退避策略网络请求失败后不要立即重试。实现一个简单的指数退避策略第一次失败等1秒后重试第二次失败等2秒第三次等4秒……并设置最大重试次数。这能有效避免在服务器临时故障时加剧其压力。内存管理虽然File.slice()创建的是Blob视图但如果你同时将大量分片Blob保存在内存数组中比如在chunks对象里对于超大文件仍可能导致内存压力。可以考虑“流式”处理计算完一个分片的哈希并放入队列后是否可以考虑释放对该分片Blob的引用这需要仔细设计数据流但能提升超大文件上传的稳定性。最后一点个人体会断点续传是一个看似简单、实则细节繁多的功能。它完美地结合了前端性能优化、网络编程、状态管理和用户体验设计。自己动手实现一遍你会对前端如何处理二进制数据、如何与Worker通信、如何设计有状态的任务调度有更深的理解。这套模式不仅用于文件上传其思想分治、状态持久化、异步队列可以迁移到很多其他需要处理大量数据或长任务的场景中。
