#如何系统性地设计一个支持大文件上传和断点续传的方案面试答案核心架构“三驾马车”一个成熟的方案通常是三大核心技术的组合分片上传 (Chunked Upload)、断点续传 (Resumable Upload)和秒传 (Instant Upload)。分片上传为传输大文件“搭脚手架”是什么前端用Blob.prototype.slice()把大文件切成一个个几MB如5MB的数据块。后端用一个UploadId来标识这次任务最后再把这些“积木”按顺序拼回去。它能避开浏览器限制内存压力也小得多。为什么要分片这是实现断点续传和秒传的基础因为后续的一切操作都是以“片”为单位进行的。断点续传中断恢复的“记分牌”怎么工作上传中断后前端会问后端“这个文件之前传了哪些块”然后只继续传缺失的部分。如何落地后端需要一个地方比如用Redis存哈希或数据库表来记录每个fileHash对应的已上传分片列表。前端把上传进度存在localStorage或indexedDB里这样就算关了浏览器回来还能从断点接着传。秒传消灭重复传输的“加速器”魔法在哪里上传前先用Web Worker在后台算出文件指纹fileHash比如MD5。后端一查如果这个哈希值已经存在可能服务器上已经有这个文件了立刻返回“上传成功”。对用户来说几GB的文件是“秒传”的。一个隐藏好处如果哈希值对应的文件只传了50%比如上次中断了就可以实现“准秒传”无缝衔接断点续传流程。前后端分工流程视频和资料都会强调一个标准流程前端准备用Web Worker计算fileHash避免界面卡顿。秒传校验后端通过fileHash判断文件或部分文件是否存在。获取断点若有缺失后端返回已上传的分片列表前端过滤出未上传的分片。并发上传将未上传的分片并发上传到后端如服务器或直传OSS并发数通常限制在3-5个。合并与校验所有分片传完后请求后端合并最后再校验整个文件的哈希。 面试官的追问与避坑指南面试官通常会深入追问和考察“坑点”下面这几个点能帮你提前做好准备网络中断与恢复前端需要能主动暂停通过XHR.abort()恢复时重新执行流程获取断点。多用户并发保证稳定性后端应利用消息队列如RabbitMQ将文件合并等耗时任务异步处理避免长时间阻塞主线程。分片完整性校验确保文件合并后完整无损。这需要两次哈希校验上传时验证每个分片的MD5合并后再验证整个文件的MD5。文件合并为避免内存溢出服务端合并分片要使用RandomAccessFile或Java NIO进行流式读写绝不能一次性加载所有分片到内存。临时分片清理必须有机制定期如24小时后清理未完成的临时分片防止存储空间被无效数据占满。安全性上传接口必须有严格的权限控制防止未授权上传和数据泄露。#大文件上传与断点续传的坑️ 十大常见“坑”及其破解之道常见“坑”现象 / 易错点根本原因解决方案 / 最佳实践坑1分片顺序错乱并发上传多个分片后端按接收顺序追加写入导致文件损坏网络延迟导致先发的分片后到后端若按顺序追加则分片顺序错乱后端必须按chunkIndex排序后合并绝不能依赖接收顺序坑2完整性校验缺失合并后的文件损坏或与原文件不符只靠分片序号拼接缺少端到端完整性校验二次哈希校验上传时校验单个分片 MD5合并后校验整个文件 MD5坑3文件标识错误同名文件并发上传时分片“串片”或相互覆盖仅用文件名作为唯一标识不同用户/不同内容的同名文件无法区分服务端应使用fileId如fileHash 随机UUID隔离不同文件不能仅用文件名坑4分片/元数据存储性能问题大文件切分片数太多元数据存储消耗过大如 50GB 文件切 5MB/片 ≈ 10000 个 Key高并发下元数据存储成为新瓶颈控制合理切分颗粒度元数据存储需考虑 TTL 自动清理机制定期清理 24 小时未完成上传的临时分片坑5内存爆炸服务器在处理大文件合并时内存溢出OOM后端一次性将所有分片加载到内存再拼接或前端一次上传超大 FormData流式合并如Files.copy或transferFrom零拷贝禁止全量加载进内存坑6断点续传无法恢复网络恢复后前端无法从中断处继续上传仍从头开始服务端缺少记录已上传分片状态的接口或接口响应未返回明确的缺失分片列表服务端需提供GET /upload/status?uploadIdxxx接口返回已上传的分片索引列表坑7分片重复写入/脏数据网络超时重试导致分片被重复写入异常中断产生半截文件服务端未实现分片接收的幂等性校验文件写入操作非原子每个uploadId chunkIndex写入前先校验是否存在存在则直接跳过使用原子写入操作坑8合并卡死/超时最后一步合并分片请求耗时过长连接超时导致上传失败合并逻辑在 HTTP 请求线程中同步执行阻塞 IO且未考虑超时和异步处理合并操作改为后台异步执行合并完成后通过回调/轮询通知客户端同步合并仅适用于小文件坑9存储资源泄漏用户上传失败或放弃后临时分片永远堆积消耗大量存储空间缺少临时分片的自动清理机制增加定时清理任务定期删除超过一定时间如 24 小时未完成合并的临时分片坑10大文件 MD5 计算导致前端卡死用户选择 50GB 文件后浏览器假死崩溃JS 主线程计算全量 MD5 是 CPU 密集型操作导致页面阻塞使用Web Worker在后台线程计算或采用抽样哈希Sample Hash仅读取文件头尾 中间随机几块 文件大小 修改时间生成弱指纹用于秒传预判 进阶追问面试官的“死亡三连问”如何接招视频中面试官会基于架构深度和并发场景进一步追问抗压能力的细节追问1流直传 vs OSS直传“所有分片都经过你的 Java 服务中转万人并发上传网卡带宽瞬间被打满怎么办” —— 单应用服务器带宽和内存有限流量“过境”会形成瓶颈。高阶方案采用客户端STS 临时凭证直传 OSS/MinIO服务端只负责签发 Token文件流完全不经过业务服务器。追问2合并卡死如何异步解耦“最后一步合并打算同步进行万一合并 10 分钟连接超时服务卡死50GB 垃圾碎片谁来清” —— 合并操作改为后台异步执行服务端接收到“完成”请求后立即返回“合并中”通过轮询或 WebSocket 通知结果。追问3并发冲突如何原子化“高并发下多个请求同时修改上传状态数据乱了怎么办” —— 使用 Redis 的原子操作记录/检查分片状态如SETNX或SADD防止并发覆盖。追问4浏览器卡死如何优化“浏览器计算 50GB 文件的 MD5卡死崩溃你负责吗” ——Web Worker 后台计算或抽样哈希读取头尾 中间随机块 文件大小生成指纹。#大文件上传如何处理处理 1GB 以上的大文件上传核心挑战是网络不稳定导致上传失败重传成本高、内存与磁盘 IO 压力、服务器超时限制。解决方案通常采用前端分片 后端合并 断点续传的组合方案。面试回答概要大文件上传的核心挑战是网络不稳定、重传成本高、服务器内存压力。采用前端分片 后端合并 断点续传的方案。具体流程前端使用Blob.slice将文件切分为 5~10MB 的小块为每个分片生成序号和文件唯一标识如 MD5。并行或串行上传并记录已上传的分片索引支持断点续传上传前询问后端哪些分片已存在跳过已上传部分。后端接收分片后暂存到临时目录按文件ID/分片序号存储。待所有分片上传完成后调用合并接口按顺序将分片合并为完整文件并清理临时分片。秒传优化上传前先计算文件完整 MD5若服务器已有相同文件直接复制元数据并返回 URL无需实际传输。并发控制限制同时处理的合并任务数使用 Redis 分布式锁防止分片覆盖。另外要注意临时文件的定期清理以及对超大文件可采用云存储的原生分片上传 API如 OSS multipart upload进一步简化实现。一、整体流程前端将文件切分为多个小块如 5MB~10MB/片并行或串行上传并记录已上传的分片索引。后端接收分片临时保存按文件标识分片序号存储待所有分片上传完成后通知合并。断点续传前端询问已上传的分片列表跳过已上传部分。秒传通过文件 MD5 检查服务器是否已存在相同文件若存在则直接复制元数据。二、前端实现要点1. 分片策略使用Blob.slice或File.prototype.slice切分。分片大小建议 5~10 MB兼顾并发效率和失败重传粒度。为每个分片生成序号0~N-1和文件唯一标识如 MD5 或 UUID。2. 上传方式串行上传简单但速度慢。适合稳定性要求高的场景。并行上传提高速度但需控制并发数如 3~5 个避免网络拥塞和浏览器/服务器压力。3. 断点续传实现每次上传前调用后端接口GET /upload/status?fileIdxxx获取已上传的分片列表。跳过已上传的分片从未上传的第一个分片开始发送。上传进度 已上传分片数 / 总分片数。4. 校验与重试每个分片上传时计算分片 MD5后端校验完整性。失败分片自动重试如最多 3 次支持指数退避。5. 并发与冲突处理使用Promise.all限制并发数。对同一文件的多个上传请求后端需要加锁如 Redis 分布式锁防止分片覆盖。三、后端实现要点Java Spring Boot 示例1. 上传分片接口javaPostMapping(/upload/chunk) public Result uploadChunk( RequestParam String fileId, // 文件唯一标识 RequestParam int chunkIndex, // 分片序号 RequestParam int totalChunks, RequestParam MultipartFile chunk) { // 1. 验证参数合法性 // 2. 将分片保存到临时目录/upload/{fileId}/{chunkIndex} // 3. 可选记录分片上传状态到 Redis如 BitSet 或 Set // 4. 返回成功 }2. 合并分片接口javaPostMapping(/upload/merge) public Result merge(RequestParam String fileId, RequestParam String fileName) { // 1. 检查所有分片是否完整如检查 Redis 中的分片集合是否包含 0 到 total-1 // 2. 创建目标文件按顺序合并分片使用 FileChannel 或 Files.write // 3. 计算整个文件的 MD5与客户端上传的 MD5 比对可选 // 4. 清理临时分片目录 // 5. 记录文件元数据到数据库返回下载 URL }合并代码片段javaPath target Paths.get(uploadDir, fileName); try (FileChannel out FileChannel.open(target, CREATE, WRITE)) { for (int i 0; i totalChunks; i) { Path chunkPath Paths.get(uploadDir, fileId, String.valueOf(i)); try (FileChannel in FileChannel.open(chunkPath, READ)) { in.transferTo(0, in.size(), out); } Files.delete(chunkPath); } } Files.delete(Paths.get(uploadDir, fileId));3. 查询已上传分片接口javaGetMapping(/upload/status) public Result getUploadedChunks(RequestParam String fileId) { // 返回已存在分片的序号列表例如 [0,1,2,5] }四、断点续传与秒传的高级支持1. 秒传前端计算文件完整 MD5使用spark-md5等库分块计算避免内存溢出。后端收到 MD5 后查询数据库若已存在相同文件且路径有效则直接返回文件 URL无需上传分片。2. 失败恢复如果合并过程中断可记录合并状态支持重新合并。定时清理未完成的分片例如 24 小时未合并的临时文件。3. 并发控制使用 Redis 原子操作SETNX或INCR限制同时处理的合并任务数防止磁盘 IO 过载。五、优化与注意事项限制并发上传连接数后端可限制每个用户同时上传的文件数防止资源耗尽。使用异步处理合并大文件可能耗时较长可以立即返回taskId由前端轮询合并结果。磁盘容量监控分片临时目录需要定期清理建议使用单独的磁盘分区。支持 OSS 直传可将分片直接上传到云存储如阿里云 OSS 分片上传后端仅做聚合和元数据管理减轻服务器压力。HTTP 超时配置前端设置较长的 read timeout如 10 分钟后端适当调整连接超时。六、前端分片计算示例简单 HTML JS 逻辑javascriptasync function uploadFile(file) { const CHUNK_SIZE 5 * 1024 * 1024; // 5MB const totalChunks Math.ceil(file.size / CHUNK_SIZE); const fileId await getFileHash(file); // 计算 MD5 const uploaded await getUploadedChunks(fileId); for (let i 0; i totalChunks; i) { if (uploaded.includes(i)) continue; const start i * CHUNK_SIZE; const chunk file.slice(start, start CHUNK_SIZE); const formData new FormData(); formData.append(fileId, fileId); formData.append(chunkIndex, i); formData.append(totalChunks, totalChunks); formData.append(chunk, chunk); await fetch(/upload/chunk, { method: POST, body: formData }); // 更新进度 UI } await fetch(/upload/merge, { method: POST, body: JSON.stringify({fileId, fileName: file.name}) }); }七、总结大文件上传推荐采用“前端分片 后端合并 断点续传 秒传”方案。前端负责切块、并发控制、断点续传。后端负责分片接收、完整性校验、合并及清理。对于超大文件10GB可考虑使用云存储原生的分片上传 API如 AWS S3 multipart upload更稳定高效。
#如何系统性地设计一个支持大文件上传和断点续传的方案面试答案核心架构“三驾马车”一个成熟的方案通常是三大核心技术的组合分片上传 (Chunked Upload)、断点续传 (Resumable Upload)和秒传 (Instant Upload)。分片上传为传输大文件“搭脚手架”是什么前端用Blob.prototype.slice()把大文件切成一个个几MB如5MB的数据块。后端用一个UploadId来标识这次任务最后再把这些“积木”按顺序拼回去。它能避开浏览器限制内存压力也小得多。为什么要分片这是实现断点续传和秒传的基础因为后续的一切操作都是以“片”为单位进行的。断点续传中断恢复的“记分牌”怎么工作上传中断后前端会问后端“这个文件之前传了哪些块”然后只继续传缺失的部分。如何落地后端需要一个地方比如用Redis存哈希或数据库表来记录每个fileHash对应的已上传分片列表。前端把上传进度存在localStorage或indexedDB里这样就算关了浏览器回来还能从断点接着传。秒传消灭重复传输的“加速器”魔法在哪里上传前先用Web Worker在后台算出文件指纹fileHash比如MD5。后端一查如果这个哈希值已经存在可能服务器上已经有这个文件了立刻返回“上传成功”。对用户来说几GB的文件是“秒传”的。一个隐藏好处如果哈希值对应的文件只传了50%比如上次中断了就可以实现“准秒传”无缝衔接断点续传流程。前后端分工流程视频和资料都会强调一个标准流程前端准备用Web Worker计算fileHash避免界面卡顿。秒传校验后端通过fileHash判断文件或部分文件是否存在。获取断点若有缺失后端返回已上传的分片列表前端过滤出未上传的分片。并发上传将未上传的分片并发上传到后端如服务器或直传OSS并发数通常限制在3-5个。合并与校验所有分片传完后请求后端合并最后再校验整个文件的哈希。 面试官的追问与避坑指南面试官通常会深入追问和考察“坑点”下面这几个点能帮你提前做好准备网络中断与恢复前端需要能主动暂停通过XHR.abort()恢复时重新执行流程获取断点。多用户并发保证稳定性后端应利用消息队列如RabbitMQ将文件合并等耗时任务异步处理避免长时间阻塞主线程。分片完整性校验确保文件合并后完整无损。这需要两次哈希校验上传时验证每个分片的MD5合并后再验证整个文件的MD5。文件合并为避免内存溢出服务端合并分片要使用RandomAccessFile或Java NIO进行流式读写绝不能一次性加载所有分片到内存。临时分片清理必须有机制定期如24小时后清理未完成的临时分片防止存储空间被无效数据占满。安全性上传接口必须有严格的权限控制防止未授权上传和数据泄露。#大文件上传与断点续传的坑️ 十大常见“坑”及其破解之道常见“坑”现象 / 易错点根本原因解决方案 / 最佳实践坑1分片顺序错乱并发上传多个分片后端按接收顺序追加写入导致文件损坏网络延迟导致先发的分片后到后端若按顺序追加则分片顺序错乱后端必须按chunkIndex排序后合并绝不能依赖接收顺序坑2完整性校验缺失合并后的文件损坏或与原文件不符只靠分片序号拼接缺少端到端完整性校验二次哈希校验上传时校验单个分片 MD5合并后校验整个文件 MD5坑3文件标识错误同名文件并发上传时分片“串片”或相互覆盖仅用文件名作为唯一标识不同用户/不同内容的同名文件无法区分服务端应使用fileId如fileHash 随机UUID隔离不同文件不能仅用文件名坑4分片/元数据存储性能问题大文件切分片数太多元数据存储消耗过大如 50GB 文件切 5MB/片 ≈ 10000 个 Key高并发下元数据存储成为新瓶颈控制合理切分颗粒度元数据存储需考虑 TTL 自动清理机制定期清理 24 小时未完成上传的临时分片坑5内存爆炸服务器在处理大文件合并时内存溢出OOM后端一次性将所有分片加载到内存再拼接或前端一次上传超大 FormData流式合并如Files.copy或transferFrom零拷贝禁止全量加载进内存坑6断点续传无法恢复网络恢复后前端无法从中断处继续上传仍从头开始服务端缺少记录已上传分片状态的接口或接口响应未返回明确的缺失分片列表服务端需提供GET /upload/status?uploadIdxxx接口返回已上传的分片索引列表坑7分片重复写入/脏数据网络超时重试导致分片被重复写入异常中断产生半截文件服务端未实现分片接收的幂等性校验文件写入操作非原子每个uploadId chunkIndex写入前先校验是否存在存在则直接跳过使用原子写入操作坑8合并卡死/超时最后一步合并分片请求耗时过长连接超时导致上传失败合并逻辑在 HTTP 请求线程中同步执行阻塞 IO且未考虑超时和异步处理合并操作改为后台异步执行合并完成后通过回调/轮询通知客户端同步合并仅适用于小文件坑9存储资源泄漏用户上传失败或放弃后临时分片永远堆积消耗大量存储空间缺少临时分片的自动清理机制增加定时清理任务定期删除超过一定时间如 24 小时未完成合并的临时分片坑10大文件 MD5 计算导致前端卡死用户选择 50GB 文件后浏览器假死崩溃JS 主线程计算全量 MD5 是 CPU 密集型操作导致页面阻塞使用Web Worker在后台线程计算或采用抽样哈希Sample Hash仅读取文件头尾 中间随机几块 文件大小 修改时间生成弱指纹用于秒传预判 进阶追问面试官的“死亡三连问”如何接招视频中面试官会基于架构深度和并发场景进一步追问抗压能力的细节追问1流直传 vs OSS直传“所有分片都经过你的 Java 服务中转万人并发上传网卡带宽瞬间被打满怎么办” —— 单应用服务器带宽和内存有限流量“过境”会形成瓶颈。高阶方案采用客户端STS 临时凭证直传 OSS/MinIO服务端只负责签发 Token文件流完全不经过业务服务器。追问2合并卡死如何异步解耦“最后一步合并打算同步进行万一合并 10 分钟连接超时服务卡死50GB 垃圾碎片谁来清” —— 合并操作改为后台异步执行服务端接收到“完成”请求后立即返回“合并中”通过轮询或 WebSocket 通知结果。追问3并发冲突如何原子化“高并发下多个请求同时修改上传状态数据乱了怎么办” —— 使用 Redis 的原子操作记录/检查分片状态如SETNX或SADD防止并发覆盖。追问4浏览器卡死如何优化“浏览器计算 50GB 文件的 MD5卡死崩溃你负责吗” ——Web Worker 后台计算或抽样哈希读取头尾 中间随机块 文件大小生成指纹。#大文件上传如何处理处理 1GB 以上的大文件上传核心挑战是网络不稳定导致上传失败重传成本高、内存与磁盘 IO 压力、服务器超时限制。解决方案通常采用前端分片 后端合并 断点续传的组合方案。面试回答概要大文件上传的核心挑战是网络不稳定、重传成本高、服务器内存压力。采用前端分片 后端合并 断点续传的方案。具体流程前端使用Blob.slice将文件切分为 5~10MB 的小块为每个分片生成序号和文件唯一标识如 MD5。并行或串行上传并记录已上传的分片索引支持断点续传上传前询问后端哪些分片已存在跳过已上传部分。后端接收分片后暂存到临时目录按文件ID/分片序号存储。待所有分片上传完成后调用合并接口按顺序将分片合并为完整文件并清理临时分片。秒传优化上传前先计算文件完整 MD5若服务器已有相同文件直接复制元数据并返回 URL无需实际传输。并发控制限制同时处理的合并任务数使用 Redis 分布式锁防止分片覆盖。另外要注意临时文件的定期清理以及对超大文件可采用云存储的原生分片上传 API如 OSS multipart upload进一步简化实现。一、整体流程前端将文件切分为多个小块如 5MB~10MB/片并行或串行上传并记录已上传的分片索引。后端接收分片临时保存按文件标识分片序号存储待所有分片上传完成后通知合并。断点续传前端询问已上传的分片列表跳过已上传部分。秒传通过文件 MD5 检查服务器是否已存在相同文件若存在则直接复制元数据。二、前端实现要点1. 分片策略使用Blob.slice或File.prototype.slice切分。分片大小建议 5~10 MB兼顾并发效率和失败重传粒度。为每个分片生成序号0~N-1和文件唯一标识如 MD5 或 UUID。2. 上传方式串行上传简单但速度慢。适合稳定性要求高的场景。并行上传提高速度但需控制并发数如 3~5 个避免网络拥塞和浏览器/服务器压力。3. 断点续传实现每次上传前调用后端接口GET /upload/status?fileIdxxx获取已上传的分片列表。跳过已上传的分片从未上传的第一个分片开始发送。上传进度 已上传分片数 / 总分片数。4. 校验与重试每个分片上传时计算分片 MD5后端校验完整性。失败分片自动重试如最多 3 次支持指数退避。5. 并发与冲突处理使用Promise.all限制并发数。对同一文件的多个上传请求后端需要加锁如 Redis 分布式锁防止分片覆盖。三、后端实现要点Java Spring Boot 示例1. 上传分片接口javaPostMapping(/upload/chunk) public Result uploadChunk( RequestParam String fileId, // 文件唯一标识 RequestParam int chunkIndex, // 分片序号 RequestParam int totalChunks, RequestParam MultipartFile chunk) { // 1. 验证参数合法性 // 2. 将分片保存到临时目录/upload/{fileId}/{chunkIndex} // 3. 可选记录分片上传状态到 Redis如 BitSet 或 Set // 4. 返回成功 }2. 合并分片接口javaPostMapping(/upload/merge) public Result merge(RequestParam String fileId, RequestParam String fileName) { // 1. 检查所有分片是否完整如检查 Redis 中的分片集合是否包含 0 到 total-1 // 2. 创建目标文件按顺序合并分片使用 FileChannel 或 Files.write // 3. 计算整个文件的 MD5与客户端上传的 MD5 比对可选 // 4. 清理临时分片目录 // 5. 记录文件元数据到数据库返回下载 URL }合并代码片段javaPath target Paths.get(uploadDir, fileName); try (FileChannel out FileChannel.open(target, CREATE, WRITE)) { for (int i 0; i totalChunks; i) { Path chunkPath Paths.get(uploadDir, fileId, String.valueOf(i)); try (FileChannel in FileChannel.open(chunkPath, READ)) { in.transferTo(0, in.size(), out); } Files.delete(chunkPath); } } Files.delete(Paths.get(uploadDir, fileId));3. 查询已上传分片接口javaGetMapping(/upload/status) public Result getUploadedChunks(RequestParam String fileId) { // 返回已存在分片的序号列表例如 [0,1,2,5] }四、断点续传与秒传的高级支持1. 秒传前端计算文件完整 MD5使用spark-md5等库分块计算避免内存溢出。后端收到 MD5 后查询数据库若已存在相同文件且路径有效则直接返回文件 URL无需上传分片。2. 失败恢复如果合并过程中断可记录合并状态支持重新合并。定时清理未完成的分片例如 24 小时未合并的临时文件。3. 并发控制使用 Redis 原子操作SETNX或INCR限制同时处理的合并任务数防止磁盘 IO 过载。五、优化与注意事项限制并发上传连接数后端可限制每个用户同时上传的文件数防止资源耗尽。使用异步处理合并大文件可能耗时较长可以立即返回taskId由前端轮询合并结果。磁盘容量监控分片临时目录需要定期清理建议使用单独的磁盘分区。支持 OSS 直传可将分片直接上传到云存储如阿里云 OSS 分片上传后端仅做聚合和元数据管理减轻服务器压力。HTTP 超时配置前端设置较长的 read timeout如 10 分钟后端适当调整连接超时。六、前端分片计算示例简单 HTML JS 逻辑javascriptasync function uploadFile(file) { const CHUNK_SIZE 5 * 1024 * 1024; // 5MB const totalChunks Math.ceil(file.size / CHUNK_SIZE); const fileId await getFileHash(file); // 计算 MD5 const uploaded await getUploadedChunks(fileId); for (let i 0; i totalChunks; i) { if (uploaded.includes(i)) continue; const start i * CHUNK_SIZE; const chunk file.slice(start, start CHUNK_SIZE); const formData new FormData(); formData.append(fileId, fileId); formData.append(chunkIndex, i); formData.append(totalChunks, totalChunks); formData.append(chunk, chunk); await fetch(/upload/chunk, { method: POST, body: formData }); // 更新进度 UI } await fetch(/upload/merge, { method: POST, body: JSON.stringify({fileId, fileName: file.name}) }); }七、总结大文件上传推荐采用“前端分片 后端合并 断点续传 秒传”方案。前端负责切块、并发控制、断点续传。后端负责分片接收、完整性校验、合并及清理。对于超大文件10GB可考虑使用云存储原生的分片上传 API如 AWS S3 multipart upload更稳定高效。
