上传大文件失败要重头再来这件事干过一次就再也不想碰第二次。所以我把断点续传从“能用”做到“好用”从用户体验到服务端压力都梳理了一遍这篇文章就围绕Vue生态下的断点续传实现、性能瓶颈和优化手段展开适合正在做大文件上传模块、被切片策略和内存占用折磨过的前端同学参考。先说结论断点续传的本质不是“传得更快”而是“失败后不用从头再来”。真正的性能提升来自三件事——减少重复计算、控制并发节奏、降低内存压力。这三件事不做好就算把分片大小调来调去也是白搭。1. 断点续传的核心链路拆解1.1 从一次上传失败说起早先做的内部工具上传一个2GB的网页录制文件传到80%时办公室路由器抽风进度条直接归零。那时候的实现是multipart/form-data一把梭文件整包塞进请求体失败了就重新选文件再传一次。用户体验差是一回事服务端临时盘还要反复容纳这么大的请求体带宽和磁盘IO都被白白浪费。后来改成切片上传核心思路很简单把文件切成若干块每块独立上传服务端按序号拼接。真正落地时才发现切片上传只是断点续传的基础它本身并不等于“体验好”。断点续传的完整链路有四个环节文件切片、指纹计算、分片上传、服务端合并。其中任何一步没处理好都会在后续优化时变成瓶颈。1.2 断点续传的关键环节第一个环节是切片。前端拿到的文件是File对象底层是Blob可以直接用Blob.prototype.slice方法切出子块。切片大小没有固定标准常见方案是固定大小比如5MB、10MB、20MB也有动态切片的做法。我项目里一开始用固定10MB后来改成按文件大小动态设置这部分在后面性能优化里单独讲。第二个环节是计算文件指纹通常用Hash比如MD5、SHA-1、SHA-256。这一步的目的有两个一是给文件一个全局唯一标识让服务端判断“这个文件之前传没传过”二是给每个分片算独立标识方便做秒传和断点校验。这里踩过一个坑直接用crypto-js在主线程算一个2GB文件的MD5页面直接卡了十几秒期间用户点任何按钮都没反应。为什么因为文件Hash计算是CPU密集型的IO加运算任务主线程被同步循环占住浏览器来不及处理渲染和事件响应。解决办法是Web Worker后面细说。第三个环节是分片上传。每个分片都是独立的HTTP请求一般用PUT或POST请求体就是分片的Blob。服务端要支持按文件标识和分片序号存储并且最好做幂等处理——同一个分片重复上传应当直接返回成功而不是覆盖出错。第四个环节是服务端合并。全部切片传完后前端调用一个合并接口服务端按分片序号把临时文件拼接成完整文件再做一次大小或Hash校验。合并接口看起来简单但并发上传场景下很容易出问题某个分片还没传完合并请求就到了服务端必须校验分片完整性再合并否则极大概率产出损坏文件。1.3 整包上传与切片上传的取舍为什么不能直接走后端分片比如nginx有client_max_body_size限制不改配置的话请求体超过默认值直接413。即便改了配置整包上传时任何一个中间环节的闪断都会导致整个请求失败TCP重传和超时会让恢复时间不可控。切片上传把一个大请求拆成了多个小请求好处有三点单请求体积小单次失败影响范围有限可以并发发送多个分片充分利用带宽服务端可以提前落盘失败后能定位到具体分片。但切片不是越多越好。分片数量过多会导致请求数和文件句柄数剧增服务端的临时文件管理、合并排序、Hash校验都会变慢。所以切片大小和并发数是要平衡的不是拍脑袋定的。2. 大文件上传的性能瓶颈到底在哪2.1 四个典型的卡点实际压测和线上反馈下来大文件上传的性能问题集中在四个方面第一主线程Hash计算卡死界面。文件越大越严重2GB以上的文件在普通配置的机器上主线程计算MD5耗时基本在十秒以上用户感知就是上传页面无响应。第二并发数过高导致请求排队和网络拥塞。有人一开始为了追求速度把分片并发调到10个甚至20个结果上行带宽有限所有请求同时抢带宽每个分片的耗时反而变长而且服务端压力陡增。更糟糕的是部分浏览器对同域名并发连接数有限制超出连接数上限的请求会排队等待速度不升反降。第三内存占用失控。如果一次性把所有分片都读进内存或者用FileReader读大块数据到ArrayBuffer浏览器内存很快飙升移动端直接白屏或崩溃。第四进度条来回跳。进度条不是单调递增的而是根据已完成分片数量除以总分片数计算并发场景下可能出现“卡在99%”很久的假象用户以为卡死了其实是最后几个大分片或合并操作还在进行。2.2 计算Hash为什么会卡死主线程常规写法是这样import SparkMD5 from spark-md5 function calculateHash(file) { return new Promise((resolve, reject) { const chunkSize 2 * 1024 * 1024 const chunks Math.ceil(file.size / chunkSize) const spark new SparkMD5.ArrayBuffer() const fileReader new FileReader() let index 0 fileReader.onload (e) { spark.append(e.target.result) index if (index chunks) { loadNext() } else { resolve(spark.end()) } } fileReader.onerror reject function loadNext() { const start index * chunkSize const end Math.min(start chunkSize, file.size) fileReader.readAsArrayBuffer(file.slice(start, end)) } loadNext() }) }这段代码本身没错问题在于它跑在主线程。每次readAsArrayBuffer读2MB数据然后spark.append这是一个持续的同步计算过程。文件越大、循环次数越多主线程就越忙浏览器的渲染、事件响应、动画全部卡顿。这里有个经验之谈2MB的切片粒度跑MD5在小文件上没问题但大文件场景下建议把Hash粒度加大比如10MB一读减少IO循环次数。Hash校验的精度不会因为读取粒度变大而下降因为最终是整体文件的Hash不是分片的。2.3 并发上传的“假快”与真慢最开始做并发时我直接用Promise.all把全部分片一次性怼给服务端。几百个分片同时发先不说浏览器连接数限制单是服务端的临时文件IO就吃不消而且一旦某个分片失败整个Promise.all抛错前面的成功分片也拿不到结果恢复逻辑变得很尴尬。后来改成固定并发数的调度器比如同时允许3个分片在上传完成一个从队列里补一个。这样控制住了请求水位服务端不会被打满前端也能准确拿到每个分片的状态。核心调度逻辑类似这样async function uploadWithConcurrency(tasks, limit 3) { const results new Array(tasks.length) let index 0 async function worker() { while (index tasks.length) { const current index try { results[current] await tasks[current]() } catch (err) { results[current] { error: err } } } } const workers Array.from({ length: limit }, () worker()) await Promise.all(workers) return results }关键点是控制任务队列而不是一次性并发所有分片。3. 性能提升的几个关键手段3.1 用Web Worker算文件指纹把Hash计算迁移到Web Worker之后主线程只负责通信和进度展示界面再也不卡了。这里有几个细节值得注意。首先是Worker内部仍然不能把整个文件读进内存还是要分块读取。正确姿势是File对象可以通过postMessage传给WorkerWorker内部拿到File后用slice和FileReader读取。示例代码// worker.js self.onmessage async (e) { const { file, chunkSize } e.data const spark new SparkMD5.ArrayBuffer() let offset 0 while (offset file.size) { const chunk file.slice(offset, offset chunkSize) const buffer await chunk.arrayBuffer() spark.append(buffer) offset chunkSize self.postMessage({ type: progress, percent: Math.min(100, Math.round((offset / file.size) * 100)) }) } self.postMessage({ type: done, hash: spark.end() }) }主线程这边用Worker实例接收消息const worker new Worker(/hash-worker.js) worker.postMessage({ file, chunkSize: 10 * 1024 * 1024 }) worker.onmessage (e) { if (e.data.type progress) { state.hashProgress e.data.percent } else if (e.data.type done) { state.fileHash e.data.hash worker.terminate() } }Worker虽然解决了卡顿问题但它也会占用一部分内存。计算完成后记得worker.terminate()释放资源不要一直挂着。我之前见过有人全局维护了一个Worker实例文件传完也不销毁结果上传多个文件后内存一直在涨。3.2 并发数控制在多少合适并发数不是一个固定值它跟网络环境、服务端能力、文件大小都有关系。我的实践经验分成两档普通场景推荐3~4个并发。这个数值在大多数带宽和服务器配置下都不会太激进稳定性最好。内网环境或经过压测的服务端可以调高到6~8个。内网带宽大、延迟低多并发能明显提速但前提是服务端接口能扛住。实际项目里可以做成自适应先测量最近N个分片的平均耗时如果耗时持续降低就尝试增加并发如果出现超时或失败就降低并发。这个机制不算复杂但收益明显。有一个反向指标值得注意并发数提升不一定带来线性收益。当单分片耗时中包含大量网络握手和TLS开销时提升并发确实能降低等待时间但一旦带宽成为瓶颈并发再高也只是让每个分片都变慢。3.3 分片大小自适应策略固定分片大小在大文件场景下会产生大量分片。1GB文件按2MB切就是512个分片元数据太多服务端合并排序的开销也大。合理策略是按文件大小动态调整文件大小建议分片大小大概分片数量0 ~ 100MB2MB最多50个100MB ~ 1GB10MB最多100个1GB ~ 5GB20MB最多250个5GB以上50MB最少100个最多500个这个策略的核心是控制分片总数在一个合理区间内既不让切片太多带来调度开销也不让单分片太大导致重传代价过高。分片大小还会影响内存占用。如果用File.slice得到的分片直接作为FormData的一部分发送那是流式读取内存压力不大。如果先用arrayBuffer()把分片读进内存再处理内存就跟着分片大小走。所以分片越大对客户端内存占用越高这是调大分片时要额外注意的代价。3.4 秒传与秒验把上传变成查重秒传的逻辑很简单前端计算文件Hash后先调用一个“查询文件状态”的接口服务端返回“文件已存在”就直接跳过上传返回“部分分片已存在”就只传缺失的分片。这个机制对重复文件特别友好。团队内很多人传同一个安装包或者同一个录制视频反复上传命中秒传和秒验后基本零等待。秒验的判断逻辑要做得精细一点不能只查一个文件级状态还要返回缺失的分片序号列表。前端拿到这个列表后把已存在的分片标记为“跳过”只上传列表中缺失的分片。这样断点续传的实现就非常干净了——不是靠前端本地记录而是靠服务端状态来判断。这里的坑在Hash碰撞。如果只用文件大小加文件名做标识重复上传同名同大小但内容不同的文件会出问题。所以我一般至少用文件大小 分片序号 全文件Hash三个维度做标识。如果要更稳妥可以对前1MB和最后1MB的数据做二次校验减少极端情况下的碰撞概率。3.5 断点恢复与网络容错断点恢复有两种做法。一种是前端本地持久化上传进度比如存localStorage或IndexedDB另一种是依赖服务端的分片状态查询。我更推荐后者因为前端的本地状态可能因为换浏览器、清缓存而丢失而服务端存储的分片状态才是权威数据。流程是这样的用户再次选择同一个文件前端算Hash调查询接口拿到已有分片列表过滤后只传缺失分片。整个过程对用户来说是透明的不需要手动点击“继续上传”。网络容错方面要做好单分片失败重试。我一般设置最多重试3次每次间隔1秒、2秒、4秒按指数退避。超过重试次数就把该分片标记为失败中止整体上传并提示用户。如果失败的分片数占总量很小可以只标记并继续其他分片最后统一补传失败分片。4. Vue工程化落地从Demo到可维护项目4.1 用组合式API封装整体上传逻辑在Vue项目里不要把断点续传的逻辑直接写在组件里太臃肿了。推荐用组合式API把整个上传过程封装成一个useUploader模块// useUploader.js import { ref } from vue import { createChunks } from ./chunk import { calculateFileHash } from ./hash import { uploadChunk, checkFileStatus, mergeFile } from ./api export function useUploader() { const progress ref(0) const status ref(idle) const uploadedChunks ref([]) async function upload(file, options) { status.value hashing const fileHash await calculateFileHash(file) const chunks createChunks(file, fileHash, options.chunkSize) status.value checking const remoteState await checkFileStatus(fileHash) if (remoteState.uploaded) { progress.value 100 status.value done return } const pendingChunks chunks.filter( (chunk) !remoteState.existingChunks.includes(chunk.index) ) status.value uploading const results await uploadWithRetry(pendingChunks, options) await mergeFile(fileHash, file.name, chunks.length) status.value done progress.value 100 } return { progress, status, uploadedChunks, upload } }组件里只需要调用upload(file, { chunkSize: 10 * 1024 * 1024, concurrency: 3 })关注状态变化和进度更新即可。4.2 组件层设计进度、取消、重试组件层要处理的交互比想象中多文件选择、拖拽上传、Hash计算进度、分片上传进度、失败重试、取消上传、暂停恢复、上传历史。我一般拆三个组件FilePicker负责文件选择与拖拽校验文件类型和大小输出File对象。UploadProgress负责展示进度包括总进度条、分片进度列表、当前上传速度、剩余时间估算。Vue里可以用watch监听progress和status变化更新UI。UploadActions负责暂停、继续、取消、重试按钮这些按钮的可用状态绑定到status枚举。进度条的建议不要只展示“已上传分片/总分数”的百分比最好结合文件大小计算一个已上传字节数。比如“3.2GB / 4.0GB剩余约2分钟”用户体验会直观很多。4.3 状态机设计与上传生命周期上传不是一个线性的“开始到结束”而是有多个中间态hashing、checking、uploading、paused、error、done。如果不做状态收敛后续加功能时很容易写出满屏if-else。我用字符串枚举来管理状态通过一个transition函数控制合法跳转const statusMap { idle: [hashing], hashing: [checking, error], checking: [uploading, done, error], uploading: [paused, error, done], paused: [uploading, error], error: [hashing, uploading], done: [] } function transition(from, to) { if (statusMap[from]?.includes(to)) { status.value to } else { console.warn(invalid transition: ${from} - ${to}) } }这个状态机从源头上拦截不合理的状态变更比如上传中不允许直接跳到done避免并发回调顺序问题导致进度异常。实测下来状态机的引入让后续的暂停、恢复、失败重试逻辑都清晰了很多。5. 常见问题与排查实录5.1 常见问题速查表问题现象可能原因排查方向Hash计算后页面卡死Hash计算跑在主线程迁移到Web Worker上传速度上不去并发数过高触发浏览器连接数上限降低并发到3~4或改用HTTP/2合并后的文件损坏分片顺序错乱或漏传服务端合并前校验分片数前端按索引确认断点恢复后重复上传大量分片服务端分片状态查询逻辑不准确校验查询接口的分片序号返回是否遗漏大文件上传时移动端崩溃内存占用过高降低单分片大小避免提前读入内存进度条99%卡很久最后几个分片未完成或合并耗时分离“上传完成”与“合并完成”两个状态5.2 实测数据与调优记录我用一个2.4GB的视频文件做了一组对比测试环境是普通千兆内网服务端是本地部署的MinIO前端是Chrome浏览器。测试结果如下方案总耗时备注不切片整包上传约85秒中途失败一次则全部重来固定5MB切片并发3约42秒稳定但Hash计算卡顿严重固定10MB切片并发3Worker计算Hash约35秒界面流畅总耗时下降动态分片并发5Worker计算Hash约28秒最优组合内存压力可控从数据看性能提升不只是一个因素的功劳。Worker解决了卡顿并发调整解决了带宽利用率动态分片减少了请求数量。三项合在一起总耗时从85秒压到了28秒左右效果相当明显。有一点必须诚实说明这些数据受网络环境、服务器硬件影响很大不同环境下的绝对数值没有直接可比性。做性能优化时一定要基于自己的项目做基准测试不要照搬别人的结论。5.3 容易踩的细节坑分片序号从0还是从1开始前后端必须对齐。这个看似小问题实际项目里见过好几次因为序号不一致导致合并后的文件错位或缺失。服务端合并接口要幂等。用户重复点击“完成上传”或者断点恢复后再次调用合并接口服务端不应该重复合并或报错。一种做法是合并前检查最终文件是否已存在存在就直接返回成功。上传接口要做超时处理。axios默认没有超时时间如果某个分片卡在网络中间件上整个上传流程会一直挂着。我会给上传接口设置一个合理的超时时间比如30秒超时后触发重试机制。Web Worker的postMessage传大文件时不同浏览器有差异。有的浏览器对结构化克隆大File对象效率很高有的会产生额外内存拷贝。如果发现Worker通信成为了瓶颈可以改为传file.slice(start, end)的小分片而不是整个File对象。关于HTTPS环境下Worker的URL要注意生产环境打包后的路径问题。直接用new Worker(/hash-worker.js)在开发环境没问题但项目部署到二级目录时路径会出误差。推荐用new URL(../workers/hash-worker.js, import.meta.url)的写法Vite和Webpack 5都支持。5.4 一个被忽视的优化点请求合并与HTTP版本大文件上传请求尤其在分片数量很多时网络握手和头部开销不可忽视。HTTP/1.1下同一个域名浏览器最多维护6个TCP连接如果分片请求很密集等待连接释放的时间会拖慢整体速度。升级到HTTP/2后多路复用允许同一连接并发传输多个请求分片请求之间的排队现象明显缓解。如果服务端和网关都支持HTTP/2建议优先开启。我压测过一次同样的并发策略下HTTP/2相比HTTP/1.1在分片场景下大约有15%左右的耗时下降主要省在了连接复用上。另外上传接口可以考虑用fetch而不是XMLHttpRequest。fetch在底层对流式请求体的支持更好配合ReadableStream还能实现真正的字节流上传避免把整个分片Buffer化。不过fetch的上传进度事件不像XHR的upload.onprogress那样直接通常需要配合ReadableStream手动统计复杂度会高一些。如果不是对进度精度有强迫症用XHR在现阶段也没问题。大文件上传的断点续传做到“能传”只是及格线做到“传得稳、传得快、失败不痛苦”才算真正落地。我实际做完这一轮优化后最深的体会是不要过分迷信某个单项技术Worker、并发、分片、状态机各自解决的只是链路中的一个环节真正让用户觉得好用的是这整条链路的稳定性和兜底机制。后面如果还想继续扩展可以在这个基础上加服务端秒传的存储策略优化、异步转码任务的联动、以及上传大文件到对象存储时的直传方案这些都是很有意思的方向。