分片上传将大文件切块传输，提升稳定性与用户体验；断点续传通过文件哈希标识、服务器进度记录、客户端状态保存等机制，实现中断后续传，解决网络不稳定、服务器压力、超时限制等问题。
表单中的大文件分片上传，简单来说，就是把一个大文件切分成很多小块，然后一块一块地上传到服务器。至于断点续传，那是在这个基础上，如果上传过程中断了，比如网络突然没了，或者用户刷新了页面，下次还能从上次中断的地方继续传，而不是从头再来。这玩意儿对于用户体验和系统稳定性来说，简直是救命稻草。
解决方案
实现分片上传和断点续传，客户端和服务器端都需要做一些工作。
客户端（前端）
文件切片： 核心是使用
File
对象的
slice
方法（或者旧的
webkitSlice
/
mozSlice
）。你可以根据预设的块大小（比如1MB或5MB）来切分文件。
const file = document.getElementById('fileInput').files[0];const chunkSize = 5 * 1024 * 1024; // 5MBlet 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 { console.error('网络错误或服务器异常:', error); // 错误处理，可能需要记录当前进度以便续传 });}// 启动上传uploadChunk();
生成文件唯一标识： 这是断点续传的关键。通常使用文件的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(); });
进度管理与状态保存： 客户端需要知道当前上传到了哪一块。断点续传时，启动上传前，先向服务器查询该文件（通过唯一标识）已经上传了多少块。服务器返回已上传的块索引列表，客户端根据这个列表跳过已上传的块，从下一个未上传的块开始。为了防止浏览器关闭导致进度丢失，可以将当前上传进度（文件哈希、已上传块索引）保存在
localStorage
或
IndexedDB
中。
服务器端（后端）
接收文件块： 服务器端需要一个接口来接收客户端上传的每一个文件块。每个请求应包含文件唯一标识、当前块的索引、总块数等信息。
存储文件块： 接收到文件块后，服务器需要将其临时存储起来。通常是存储在一个以文件唯一标识命名的临时目录下，每个块以其索引命名。例如：
/tmp/uploads/file_hash_abc/0.chunk
,
/tmp/uploads/file_hash_abc/1.chunk
。
记录上传进度： 服务器端需要持久化地记录每个文件的上传进度。这可以通过数据库（如MongoDB、Redis或关系型数据库）来实现，存储文件唯一标识、已上传的块索引列表、文件状态（上传中、已完成）等。当客户端请求续传时，服务器查询这些信息，返回已上传的块列表。
文件合并： 当服务器接收到所有文件块后（通过比对已上传块数与总块数），它需要将这些分散的块按照正确的顺序合并成一个完整的文件。合并完成后，删除临时文件块。
// 伪代码：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 { 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); // 从第一个块开始合并});
校验与清理： 合并完成后，可以对合并后的文件进行哈希校验，确保其与客户端提供的原始文件哈希一致，防止数据损坏。同时，清理临时存储的块文件和相关的进度记录。
为什么我们需要分片上传？它解决了哪些痛点？
讲真，当文件达到几十兆甚至几个G的时候，传统的单文件上传方式简直是灾难。我记得以前做项目，客户要求上传视频，动不动就是几百兆，结果浏览器直接崩溃，或者服务器超时。分片上传的出现，就是为了解决这些实实在在的痛点：
网络不稳定性： 这是最直接的。想象一下，你上传一个2GB的文件，传到99%的时候网络断了，或者服务器突然抽风，那之前所有的努力都白费了。分片上传配合断点续传，哪怕只传了一小块，进度也能保存下来，下次接着传，大大降低了失败的风险和用户的挫败感。服务器内存和处理压力： 服务器在接收文件时，往往需要将整个文件加载到内存中进行处理。对于大文件来说，这会迅速耗尽服务器资源，导致其他请求响应变慢甚至崩溃。分片上传让服务器每次只处理一小部分数据，显著降低了单次请求的内存占用和CPU压力。HTTP协议限制与超时： 很多服务器和代理对单个HTTP请求的上传时间或文件大小有硬性限制。大文件上传很容易触及这些限制导致超时。分片上传将一个大请求拆分成多个小请求，每个请求都在可控的时间内完成，有效规避了这些限制。用户体验： 用户上传大文件时，如果没有任何进度反馈，会感到焦虑。分片上传可以实时显示上传进度（已上传多少块/百分比），让用户心里有底。而且，如果支持暂停和恢复，用户体验会更上一层楼。带宽利用率： 有时候网络带宽不稳定，分片上传可以在网络状况较好时快速上传，网络状况不佳时暂停或减速，更加灵活。
所以，分片上传不仅仅是技术上的优化，更是对用户体验和系统健壮性的一种保障。
实现断点续传的关键技术点有哪些？
断点续传听起来挺玄乎，但拆解开来，无非就是几个关键环节的巧妙配合。
文件唯一标识符： 这是基石。每次上传一个文件，无论它被切成多少片，它都必须有一个全局唯一的ID。通常我们会用文件的哈希值（MD5、SHA-256）来做这个ID。为什么用哈希？因为即使文件名变了，内容没变，哈希值也一样，这能有效识别同一个文件。客户端在上传前计算出这个哈希，然后每次上传分片时都带上它。服务器端就根据这个哈希来识别文件，并管理其对应的所有分片。服务器端进度持久化： 客户端上传了一个分片，服务器接收并保存后，必须把这个分片的“已完成”状态记录下来。这个记录不能只放在内存里，因为服务器重启就没了。所以，需要将已上传的分片索引（或者已上传的分片列表）存储到数据库（比如MySQL、Redis）中，与文件唯一标识符关联起来。这样，即使服务器挂了，或者客户端下次再来，也能知道哪些分片已经传过。客户端状态管理与续传逻辑： 当用户再次尝试上传同一个文件时，客户端首先会计算这个文件的哈希。然后，带着这个哈希去问服务器：“嘿，我这个文件你是不是已经有部分了？” 服务器查询数据库，把已上传的分片列表返回给客户端。客户端拿到这个列表后，就知道哪些分片不用再传了，直接从第一个未上传的分片开始继续上传。为了更友好的用户体验，客户端还可以把当前上传的哈希和进度保存在浏览器本地存储（
localStorage
或
IndexedDB
）里，这样即使浏览器关闭，下次打开也能尝试自动恢复。分片校验与完整性： 在实际操作中，网络传输可能出现问题，导致分片数据损坏。为了确保每个分片数据的正确性，可以在上传每个分片时，客户端计算该分片的哈希值并一同发送给服务器。服务器接收分片后，也计算一次哈希，与客户端发来的进行比对。如果哈希不一致，说明数据损坏，需要客户端重新上传这个分片。虽然增加了计算开销，但对于数据完整性至关重要。
这些点环环相扣，缺一不可。任何一个环节的缺失或设计缺陷，都可能导致断点续传功能形同虚设。
分片上传和断点续传在实际应用中会遇到哪些挑战？
虽然分片上传和断点续传听起来很美，但在实际落地过程中，总会遇到一些意想不到的坑，或者说，需要更细致考量的地方。这就像你搭一个复杂的乐高模型，有些小零件总是不那么容易卡到位。
服务器存储与清理策略： 临时分片文件会占用大量磁盘空间。如果用户上传到一半取消了，或者网络中断后一直没恢复，这些未完成的临时分片就会变成“垃圾文件”。服务器需要一套完善的清理机制，比如定时任务扫描过期或长时间未更新的临时文件并删除，或者在文件上传成功合并后立即删除所有分片。这需要权衡存储成本和数据恢复的可能性。并发与竞态条件： 想象一下，同一个用户在不同设备上同时上传同一个文件，或者多个用户同时上传同一个哈希的文件（比如某个公共素材库）。服务器如何处理这些并发请求？是否需要对文件哈希加锁，防止多个客户端同时尝试合并同一个文件，导致数据混乱或重复合并？或者如何确保服务器在接收到所有分片后，只进行一次合并操作？网络波动与重试机制： 实际网络环境复杂多变，分片上传过程中，某个分片请求可能会失败（超时、5xx错误等）。客户端需要有健壮的重试机制，比如指数退避算法，在失败后等待一段时间再重试，而不是立即重试导致服务器压力更大。同时，要设置最大重试次数，避免无限循环。前端用户体验与交互： 上传过程中的进度条、暂停/恢复按钮、错误提示、成功通知等，都需要精心设计。特别是当用户刷新页面后，如何无缝地恢复上传？这可能需要前端将文件哈希、已上传进度等信息持久化到
localStorage
或
IndexedDB
，并在页面加载时检查是否有未完成的上传任务。安全性考量： 文件上传永远是安全漏洞的高发区。分片上传也不例外。需要对上传的文件类型、大小进行严格校验（MIME类型、文件头魔术字、文件大小），防止恶意文件上传。合并后的文件也需要进行二次校验。此外，文件上传接口应进行身份认证和权限控制，防止未授权访问。文件合并效率： 当文件非常大，分片数量很多时，服务器端的文件合并操作可能会耗时。如果合并过程是同步的，可能会阻塞其他请求。因此，通常会将文件合并操作放入后台任务队列（如使用消息队列或异步任务）中处理，合并完成后再通知客户端。这增加了系统的复杂性，但提升了可伸缩性。跨域问题： 如果前端和文件上传服务不在同一个域下，会遇到CORS（跨域资源共享）问题。需要服务器端正确配置CORS头，允许来自前端域的请求。
这些挑战没有一劳永逸的解决方案，更多的是根据具体业务场景和技术栈进行权衡和取舍。但提前预见到它们，至少能让开发过程少走很多弯路。
以上就是表单中的大文件分片上传怎么实现？如何断点续传？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1572279.html
微信扫一扫 
支付宝扫一扫 
