表单中的大文件分片上传怎么实现？如何断点续传？

分片上传将大文件切块传输，提升稳定性与用户体验；断点续传通过文件哈希标识、服务器进度记录、客户端状态保存等机制，实现中断后续传，解决网络不稳定、服务器压力、超时限制等问题。

表单中的大文件分片上传，简单来说，就是把一个大文件切分成很多小块，然后一块一块地上传到服务器。至于断点续传，那是在这个基础上，如果上传过程中断了，比如网络突然没了，或者用户刷新了页面，下次还能从上次中断的地方继续传，而不是从头再来。这玩意儿对于用户体验和系统稳定性来说，简直是救命稻草。

解决方案

实现分片上传和断点续传，客户端和服务器端都需要做一些工作。

客户端（前端）

1. 文件切片： 核心是使用

   File

   对象的

   slice

   方法（或者旧的

   webkitSlice

   /

   mozSlice

   ）。你可以根据预设的块大小（比如1MB或5MB）来切分文件。

   const file = document.getElementById('fileInput').files[0]; const chunkSize = 5 * 1024 * 1024; // 5MB let currentChunk = 0; const totalChunks = Math.ceil(file.size / chunkSize);  function uploadChunk() {     const start = currentChunk * chunkSize;     const end = Math.min(file.size, start + chunkSize);     const chunk = file.slice(start, end);      const formData = new FormData();     formData.append('fileChunk', chunk);     formData.append('fileName', file.name);     formData.append('fileSize', file.size);     formData.append('chunkIndex', currentChunk);     formData.append('totalChunks', totalChunks);     formData.append('fileHash', 'unique-file-hash'); // 用于断点续传和文件校验      // 发送请求到服务器     fetch('/upload/chunk', {         method: 'POST',         body: formData     })     .then(response => response.json())     .then(data => {         if (data.success) {             currentChunk++;             if (currentChunk < totalChunks) {                 uploadChunk(); // 继续上传下一块             } else {                 console.log('文件上传完成！');                 // 通知服务器合并文件                 fetch('/upload/merge', {                     method: 'POST',                     headers: { 'Content-Type': 'application/json' },                     body: JSON.stringify({ fileName: file.name, fileHash: 'unique-file-hash', totalChunks: totalChunks })                 });             }         } else {             console.error('上传失败:', data.message);             // 处理失败逻辑，比如重试         }     })     .catch(error => {         console.error('网络错误或服务器异常:', error);         // 错误处理，可能需要记录当前进度以便续传     }); }  // 启动上传 uploadChunk();

2. 生成文件唯一标识： 这是断点续传的关键。通常使用文件的MD5或SHA-256哈希值。在文件切片之前，先计算出整个文件的哈希值。这个过程可能耗时，可以在Web Worker中进行，避免阻塞主线程。

   // 伪代码：计算文件哈希 function calculateFileHash(file) {     return new Promise((resolve, reject) => {         const reader = new FileReader();         reader.onload = function(e) {             // 使用第三方库如spark-md5或crypto-js计算哈希             const hash = SparkMD5.hashBinary(e.target.result);             resolve(hash);         };         reader.onerror = reject;         reader.readAsBinaryString(file);     }); } // 在上传前调用：calculateFileHash(file).then(hash => { fileHash = hash; uploadChunk(); });

3. 进度管理与状态保存： 客户端需要知道当前上传到了哪一块。断点续传时，启动上传前，先向服务器查询该文件（通过唯一标识）已经上传了多少块。服务器返回已上传的块索引列表，客户端根据这个列表跳过已上传的块，从下一个未上传的块开始。为了防止浏览器关闭导致进度丢失，可以将当前上传进度（文件哈希、已上传块索引）保存在

   localStorage

   或

   IndexedDB

   中。

服务器端（后端）

1. 接收文件块： 服务器端需要一个接口来接收客户端上传的每一个文件块。每个请求应包含文件唯一标识、当前块的索引、总块数等信息。

2. 存储文件块： 接收到文件块后，服务器需要将其临时存储起来。通常是存储在一个以文件唯一标识命名的临时目录下，每个块以其索引命名。 例如：

   /tmp/uploads/file_hash_abc/0.chunk

   ,

   /tmp/uploads/file_hash_abc/1.chunk

   。

3. 记录上传进度： 服务器端需要持久化地记录每个文件的上传进度。这可以通过数据库（如MongoDB、Redis或关系型数据库）来实现，存储文件唯一标识、已上传的块索引列表、文件状态（上传中、已完成）等。当客户端请求续传时，服务器查询这些信息，返回已上传的块列表。

4. 文件合并： 当服务器接收到所有文件块后（通过比对已上传块数与总块数），它需要将这些分散的块按照正确的顺序合并成一个完整的文件。合并完成后，删除临时文件块。

   // 伪代码：Node.js 文件合并 const fs = require('fs'); const path = require('path');  app.post('/upload/merge', (req, res) => {     const { fileName, fileHash, totalChunks } = req.body;     const tempDir = path.join(__dirname, 'tmp', 'uploads', fileHash);     const finalFilePath = path.join(__dirname, 'uploads', fileName);      // 创建写入流     const writeStream = fs.createWriteStream(finalFilePath);      let mergedChunks = 0;     function mergeNextChunk(index) {         if (index < totalChunks) {             const chunkPath = path.join(tempDir, `${index}.chunk`);             const readStream = fs.createReadStream(chunkPath);             readStream.pipe(writeStream, { end: false }); // end: false 避免关闭 writeStream             readStream.on('end', () => {                 fs.unlink(chunkPath, () => {}); // 删除已合并的块                 mergedChunks++;                 mergeNextChunk(index + 1);             });             readStream.on('error', (err) => {                 console.error('合并块时出错:', err);                 writeStream.end(); // 关闭主写入流                 res.status(500).send({ success: false, message: '文件合并失败' });             });         } else {             writeStream.end(); // 所有块都已写入，关闭主写入流             // 清理临时目录             fs.rmdir(tempDir, { recursive: true }, () => {});             res.send({ success: true, message: '文件合并成功' });         }     }     mergeNextChunk(0); // 从第一个块开始合并 });

5. 校验与清理： 合并完成后，可以对合并后的文件进行哈希校验，确保其与客户端提供的原始文件哈希一致，防止数据损坏。同时，清理临时存储的块文件和相关的进度记录。

为什么我们需要分片上传？它解决了哪些痛点？

讲真，当文件达到几十兆甚至几个G的时候，传统的单文件上传方式简直是灾难。我记得以前做项目，客户要求上传视频，动不动就是几百兆，结果浏览器直接崩溃，或者服务器超时。分片上传的出现，就是为了解决这些实实在在的痛点：

1. 网络不稳定性： 这是最直接的。想象一下，你上传一个2GB的文件，传到99%的时候网络断了，或者服务器突然抽风，那之前所有的努力都白费了。分片上传配合断点续传，哪怕只传了一小块，进度也能保存下来，下次接着传，大大降低了失败的风险和用户的挫败感。
2. 服务器内存和处理压力： 服务器在接收文件时，往往需要将整个文件加载到内存中进行处理。对于大文件来说，这会迅速耗尽服务器资源，导致其他请求响应变慢甚至崩溃。分片上传让服务器每次只处理一小部分数据，显著降低了单次请求的内存占用和CPU压力。
3. HTTP协议限制与超时： 很多服务器和代理对单个HTTP请求的上传时间或文件大小有硬性限制。大文件上传很容易触及这些限制导致超时。分片上传将一个大请求拆分成多个小请求，每个请求都在可控的时间内完成，有效规避了这些限制。
4. 用户体验： 用户上传大文件时，如果没有任何进度反馈，会感到焦虑。分片上传可以实时显示上传进度（已上传多少块/百分比），让用户心里有底。而且，如果支持暂停和恢复，用户体验会更上一层楼。
5. 带宽利用率： 有时候网络带宽不稳定，分片上传可以在网络状况较好时快速上传，网络状况不佳时暂停或减速，更加灵活。

所以，分片上传不仅仅是技术上的优化，更是对用户体验和系统健壮性的一种保障。

实现断点续传的关键技术点有哪些？

断点续传听起来挺玄乎，但拆解开来，无非就是几个关键环节的巧妙配合。

1. 文件唯一标识符： 这是基石。每次上传一个文件，无论它被切成多少片，它都必须有一个全局唯一的ID。通常我们会用文件的哈希值（MD5、SHA-256）来做这个ID。为什么用哈希？因为即使文件名变了，内容没变，哈希值也一样，这能有效识别同一个文件。客户端在上传前计算出这个哈希，然后每次上传分片时都带上它。服务器端就根据这个哈希来识别文件，并管理其对应的所有分片。
2. 服务器端进度持久化： 客户端上传了一个分片，服务器接收并保存后，必须把这个分片的“已完成”状态记录下来。这个记录不能只放在内存里，因为服务器重启就没了。所以，需要将已上传的分片索引（或者已上传的分片列表）存储到数据库（比如MySQL、Redis）中，与文件唯一标识符关联起来。这样，即使服务器挂了，或者客户端下次再来，也能知道哪些分片已经传过。
3. 客户端状态管理与续传逻辑： 当用户再次尝试上传同一个文件时，客户端首先会计算这个文件的哈希。然后，带着这个哈希去问服务器：“嘿，我这个文件你是不是已经有部分了？” 服务器查询数据库，把已上传的分片列表返回给客户端。客户端拿到这个列表后，就知道哪些分片不用再传了，直接从第一个未上传的分片开始继续上传。为了更友好的用户体验，客户端还可以把当前上传的哈希和进度保存在浏览器本地存储（

   localStorage

   或

   IndexedDB

   ）里，这样即使浏览器关闭，下次打开也能尝试自动恢复。

4. 分片校验与完整性： 在实际操作中，网络传输可能出现问题，导致分片数据损坏。为了确保每个分片数据的正确性，可以在上传每个分片时，客户端计算该分片的哈希值并一同发送给服务器。服务器接收分片后，也计算一次哈希，与客户端发来的进行比对。如果哈希不一致，说明数据损坏，需要客户端重新上传这个分片。虽然增加了计算开销，但对于数据完整性至关重要。

这些点环环相扣，缺一不可。任何一个环节的缺失或设计缺陷，都可能导致断点续传功能形同虚设。

分片上传和断点续传在实际应用中会遇到哪些挑战？

虽然分片上传和断点续传听起来很美，但在实际落地过程中，总会遇到一些意想不到的坑，或者说，需要更细致考量的地方。这就像你搭一个复杂的乐高模型，有些小零件总是不那么容易卡到位。

1. 服务器存储与清理策略： 临时分片文件会占用大量磁盘空间。如果用户上传到一半取消了，或者网络中断后一直没恢复，这些未完成的临时分片就会变成“垃圾文件”。服务器需要一套完善的清理机制，比如定时任务扫描过期或长时间未更新的临时文件并删除，或者在文件上传成功合并后立即删除所有分片。这需要权衡存储成本和数据恢复的可能性。
2. 并发与竞态条件： 想象一下，同一个用户在不同设备上同时上传同一个文件，或者多个用户同时上传同一个哈希的文件（比如某个公共素材库）。服务器如何处理这些并发请求？是否需要对文件哈希加锁，防止多个客户端同时尝试合并同一个文件，导致数据混乱或重复合并？或者如何确保服务器在接收到所有分片后，只进行一次合并操作？
3. 网络波动与重试机制： 实际网络环境复杂多变，分片上传过程中，某个分片请求可能会失败（超时、5xx错误等）。客户端需要有健壮的重试机制，比如指数退避算法，在失败后等待一段时间再重试，而不是立即重试导致服务器压力更大。同时，要设置最大重试次数，避免无限循环。
4. 前端用户体验与交互： 上传过程中的进度条、暂停/恢复按钮、错误提示、成功通知等，都需要精心设计。特别是当用户刷新页面后，如何无缝地恢复上传？这可能需要前端将文件哈希、已上传进度等信息持久化到

   localStorage

   或

   IndexedDB

   ，并在页面加载时检查是否有未完成的上传任务。

5. 安全性考量： 文件上传永远是安全漏洞的高发区。分片上传也不例外。需要对上传的文件类型、大小进行严格校验（MIME类型、文件头魔术字、文件大小），防止恶意文件上传。合并后的文件也需要进行二次校验。此外，文件上传接口应进行身份认证和权限控制，防止未授权访问。
6. 文件合并效率： 当文件非常大，分片数量很多时，服务器端的文件合并操作可能会耗时。如果合并过程是同步的，可能会阻塞其他请求。因此，通常会将文件合并操作放入后台任务队列（如使用消息队列或异步任务）中处理，合并完成后再通知客户端。这增加了系统的复杂性，但提升了可伸缩性。
7. 跨域问题： 如果前端和文件上传服务不在同一个域下，会遇到CORS（跨域资源共享）问题。需要服务器端正确配置CORS头，允许来自前端域的请求。

这些挑战没有一劳永逸的解决方案，更多的是根据具体业务场景和技术栈进行权衡和取舍。但提前预见到它们，至少能让开发过程少走很多弯路。