在接手军工行业某数据管理平台的前端工程时我遇到了一个非常典型的“老树发新芽”问题现有业务需要上传大批量卫星视频素材单文件动辄几个GB而原有的页面基于WebUploader实现且运行环境限定在军工内网的特定国产化浏览器上。传统方案要么是一次性POST表单提交要么是Flash/Html4分块不仅经常把内存吃满而且一旦网络抖动真的会让人想原地离职。所以这次我基于JS对WebUploader做了二次改造核心目标是实现跨浏览器下的超大附件分片、断点续传与秒传能力。文章不聊UI美化纯技术落地分享我踩过的坑和实际可复用的代码思路希望能给正在做类似B端大型文件上传需求的朋友一些参考。1. 认清WebUploader的本质与改造边界1.1 WebUploader的原生机制与局限WebUploader是百度开源的一款老牌上传组件底层基于HTML5 File API和Flash Runtime。在早期B端项目中它凭借“拖拽上传”“进度回调”“并发控制”等功能收割了一大波好评。但说到超大附件和断点续传原生能力确实不够看原生uploader.upload()是整文件上传不会切片超大文件极易超时或内存溢出。分片逻辑依赖Flash Runtime在国产化浏览器或Chromium内核中Flash要么没装要么被禁用。没有自带的断点续传机制刷新页面或断网后一切归零。没有校验机制网络传输中数据损坏难以感知。而军工行业卫星视频素材的典型特点是分辨率高、码率高、时长长单文件4GB以上是家常便饭。内网虽然带宽尚可但网络稳定性受限于机房链路和跨网闸传输断线概率远高于公网。所以改造的核心需求是用现代HTML5能力补齐WebUploader在分片、容错、续传上的短板同时保留其调度管理UI和并发控制能力。1.2 改造方案的整体设计思路我没有推翻WebUploader而是保留它的任务队列和UI交互具体改造分三层文件预处理层基于File对象进行分片计算生成唯一标识MD5记录分片索引。传输控制层用HTML5XMLHttpRequest替代Flash/Runtime支持分片并发上传与失败重试。续传与秒传层基于后端接口实现分片状态查询拿到未完成的分片清单再续传剩余部分。这样做的好处是业务侧原有的uploader.on(uploadProgress)等事件回调基本不用改UI层改动极小核心逻辑收敛在自定义的Md5Worker和ChunkUploader模块里。2. 超大附件的分片策略与参数计算2.1 分片大小怎么定才合理分片大小不能拍脑袋它跟网络环境、服务器接收能力、并发数强相关。太大会导致单片传输时间过长、失败重试代价高太小会导致片数过多、MD5计算和请求次数爆炸。我常用的经验公式是分片大小 max(2MB, min(文件大小 / 1000, 10MB))但对于卫星视频这种大文件我实际更推荐固定分片策略文件大小推荐分片大小说明 1GB2MB加快MD5计算失败重试粒度小1GB ~ 5GB5MB平衡片数与传输效率 5GB10MB减少分片总数降低索引开销以4GB文件为例5MB分片大约是819片。如果并发数为3每片平均耗时2秒理论耗时约9分钟这在军工内网场景下是可接受的。2.2 文件唯一标识分片续传的前提断点续传的核心是“识别同一文件”不能只靠文件名因为不同时间上传的同名文件太多。我在项目中采用的是“文件MD5部分采样 文件大小 最后修改时间”组合策略完整计算4GB文件MD5太耗时前端体验极差。具体做法是采样计算读取文件头256KB、中间256KB、尾部256KB连同文件大小拼接后计算MD5。虽然不能做到100%唯一但对99.9%的场景已经足够。关键代码如下function computeFileIdentity(file) { return new Promise((resolve, reject) { const blobSlice File.prototype.slice || File.prototype.mozSlice || File.prototype.webkitSlice; const chunkSize 256 * 1024; const chunks [ blobSlice.call(file, 0, chunkSize), blobSlice.call(file, Math.max(0, Math.floor(file.size / 2) - chunkSize / 2), Math.max(0, Math.floor(file.size / 2) chunkSize / 2)), blobSlice.call(file, Math.max(0, file.size - chunkSize), file.size) ]; const reader new FileReader(); let index 0; const md5 new MD5(); reader.onload function(e) { md5.append(e.target.result); index; if (index chunks.length) { readNext(); } else { md5.end(); resolve({ identity: md5.hex(), size: file.size, lastModified: file.lastModified }); } }; reader.onerror reject; function readNext() { reader.readAsArrayBuffer(chunks[index]); } readNext(); }); }注意MD5()这里是一个简化示意实际项目我推荐使用spark-md5的增量接口避免把整个分片数据一次性读入内存。2.3 并发数与内存控制的取舍很多人在做分片时只关心并发数忽略了浏览器内存压力。每个分片读取到内存后如果同时发起多个请求内存中会同时存在多个ArrayBuffer。4GB文件分片虽然不会一次性全读进来但10个并发同时各持5MB数据就是50MB内存占用加上页面其他资源很容易触发浏览器崩溃。我最终把并发数调成3同时在每个分片上传完成后立即释放引用。实测在国产化浏览器Chromium 76内核上稳定运行内存占用控制在200MB以内。3. 断点续传的后端接口设计与前端对接3.1 接口契约先行前端做断点续传离不开后端配合。我设计了一套最小可用的REST接口前端和后端都按照同一份契约开发接口方法作用/upload/initPOST告知后端文件名、大小、唯一标识后端初始化上传任务返回上传ID/upload/checkGET根据上传ID查询已上传分片索引列表/upload/chunkPOST上传单个分片携带上传ID和分片索引/upload/mergePOST所有分片上传完成后通知后端合并文件这套接口设计的关键点在于check接口决定了续传的起点chunk接口保证分片的独立性和可重试性merge接口是最后一公里的闸门。3.2 续传流程的完整闭环前端续传逻辑其实不复杂核心就是“先问后传”1. 计算文件唯一标识identity 2. 调用 /upload/check 查询已上传分片 3. 得到已上传索引数组 uploadedIndexes 4. 遍历全部分片跳过已上传的上传未上传的 5. 全部完成后调用 /upload/merge这里最容易踩的坑是后端check时不要只看分片文件是否存在必须核对分片大小和MD5。否则断点后恢复时可能因为之前写入了一部分坏数据导致后续分片全部白传。我在后端合并前加了一层“分片完整性校验”发现不一致就强制前端重传该分片。另一个容易被忽略的细节秒传的隐藏逻辑。如果/upload/check返回的结果是“该文件已存在且完整”前端应该直接走/upload/merge完成秒传。这对军工行业重复上传卫星视频素材的场景太实用了同一条轨道数据可能被不同科室重复上传。3.3 跨浏览器兼容的关键处理军工内网的浏览器环境比较特殊很多还是老旧的国产化浏览器。我针对几个核心API做了兼容处理File.sliceFile.prototype.slice在不同内核有mozSlice和webkitSlice的旧前缀必须做兼容。FileReader老浏览器不支持readAsArrayBuffer需要降级用readAsBinaryString但要注意后者的性能差很多。Blob部分老内核不支持new Blob()我直接用slice出来的Blob对象不额外构造。XHR老内核不支持xhr.upload.onprogress只能用xhr.onprogress替代但拿不到上传进度只有下载响应进度。跨浏览器的核心经验是写一个兼容工具函数统一封装API业务层永远只调用封装后的方法不要在业务代码里到处判断浏览器类型。4. 实操过程中的故障实录与排查清单4.1 断点续传失效分片索引错位上线后第一个严重bug是续传后文件损坏。排查发现后端保存分片时用的是前端传的chunkIndex但并发上传时请求到达后端的顺序是乱的某分片先写入大块数据后面的请求覆盖了之前的偏移量导致数据错位。解决方案很简单后端不依赖请求到达顺序而是在/upload/merge时按照分片索引重新拼接。前端在上传分片时就带上chunkIndex后端暂存为独立临时文件合并时按索引排序拼接。这个改动让我意识到断点续传不能用“追加写”模式必须用“索引写”模式否则并发和重试永远有风险。4.2 内存泄漏MD5计算拖垮页面最初用spark-md5计算4GB文件MD5时因为一次性把整个文件读进FileReader浏览器直接卡死。排查后改用增量计算每读取一个分片就spark.append()并且读取完立即释放分片引用。如果文件特别大建议把MD5计算放到Web Worker中避免阻塞主线程。我在项目中为了减少改造量先用的是采样计算内网实测一个4GB视频计算耗时为3~5秒完全可接受就没有上Worker。但如果你们的文件有几十GBWorker是必须的。4.3 网络中断后的恢复时间过长这个问题出在重试策略上。最初遇断网就无限重试恢复后所有分片重新排队用户体验很差。后来我加了“指数退避”策略重试间隔 min(30秒, 基础间隔 * 2^(重试次数))同时利用/upload/check接口在恢复后立刻查询已上传分片跳过已完成的部分。实测恢复后续传速度比全量重传快3倍以上。4.4 常见问题速查表现象可能原因解决方案上传进度条不动并发数为1且分片过大增大并发数减小分片大小进度条跳变分片大小不均匀确保最后一片按剩余大小处理不要统一按固定大小切片续传后文件打不开分片拼接顺序错乱后端按分片索引排序拼接大数据文件上传导致浏览器崩溃分片数据未释放上传完成后置空变量降低并发数老内核浏览器不触发uploadProgress不支持该API降级使用xhr.onprogress5. 从一次数据事故反思校验机制的必须性上线后某周有用户反馈某段卫星视频在播放器内花屏。排查后发现该文件在传输过程中有一个分片发生了静默损坏。文件大小没变MD5也能对上某几个分片但拼接后数据就是错的。问题出在我当时只对分片做了大小校验没做内容校验。于是后端在/upload/check和/upload/merge两处都加了分片MD5校验前端在合并前后端会重算整个合并文件的MD5与前端提交的identity比对不一致则强制前端重传全部分片。虽然多了一些计算开销但军工场景对数据可靠性要求极高内容校验不能省。如果你们对传输可靠性要求不高可以只做大小校验但如果数据错了会造成严重后果务必加上内容级校验。另外值得一说的是分片大小、并发数、校验策略这些参数不要写死在代码里。我在项目中把它们全部抽成了配置项后端也能远程下发这样在不同链路环境下可以灵活调优不用反复发版。6. 一次真实的上线排障记录最后一次联调我们模拟了从某基地到中心机房的跨地域传输4.7GB卫星视频网络架构经过两跳三层交换机。第一次跑全量上传耗时约18分钟其中分片计算约5秒实际传输约17分钟。完成后核对文件MD5与源文件一致播放正常说明整个链路改造成功。但这过程中也暴露了一个问题中途故意断开网络业务侧检测到断网后没有自动暂停未完成的分片请求而是等XHR超时。超时时间默认120秒导致恢复网络后有多个分片还在等待超时回调占用了并发窗口。后来我在网络断开时手动调用xhr.abort()立即释放所有未完成请求重新排队。这个改动让我意识到断点续传不仅要处理“上传中断”还要处理“网络状态切换”后者对体验的影响更大。如果你正在做类似的超大附件上传需求我的建议是不要一上来就追求完美先跑通最小闭环分片上传续传再逐步加并发控制和校验。先把主体跑起来再加固比一次性大而全的方案更稳妥。
在接手军工行业某数据管理平台的前端工程时我遇到了一个非常典型的“老树发新芽”问题现有业务需要上传大批量卫星视频素材单文件动辄几个GB而原有的页面基于WebUploader实现且运行环境限定在军工内网的特定国产化浏览器上。传统方案要么是一次性POST表单提交要么是Flash/Html4分块不仅经常把内存吃满而且一旦网络抖动真的会让人想原地离职。所以这次我基于JS对WebUploader做了二次改造核心目标是实现跨浏览器下的超大附件分片、断点续传与秒传能力。文章不聊UI美化纯技术落地分享我踩过的坑和实际可复用的代码思路希望能给正在做类似B端大型文件上传需求的朋友一些参考。1. 认清WebUploader的本质与改造边界1.1 WebUploader的原生机制与局限WebUploader是百度开源的一款老牌上传组件底层基于HTML5 File API和Flash Runtime。在早期B端项目中它凭借“拖拽上传”“进度回调”“并发控制”等功能收割了一大波好评。但说到超大附件和断点续传原生能力确实不够看原生uploader.upload()是整文件上传不会切片超大文件极易超时或内存溢出。分片逻辑依赖Flash Runtime在国产化浏览器或Chromium内核中Flash要么没装要么被禁用。没有自带的断点续传机制刷新页面或断网后一切归零。没有校验机制网络传输中数据损坏难以感知。而军工行业卫星视频素材的典型特点是分辨率高、码率高、时长长单文件4GB以上是家常便饭。内网虽然带宽尚可但网络稳定性受限于机房链路和跨网闸传输断线概率远高于公网。所以改造的核心需求是用现代HTML5能力补齐WebUploader在分片、容错、续传上的短板同时保留其调度管理UI和并发控制能力。1.2 改造方案的整体设计思路我没有推翻WebUploader而是保留它的任务队列和UI交互具体改造分三层文件预处理层基于File对象进行分片计算生成唯一标识MD5记录分片索引。传输控制层用HTML5XMLHttpRequest替代Flash/Runtime支持分片并发上传与失败重试。续传与秒传层基于后端接口实现分片状态查询拿到未完成的分片清单再续传剩余部分。这样做的好处是业务侧原有的uploader.on(uploadProgress)等事件回调基本不用改UI层改动极小核心逻辑收敛在自定义的Md5Worker和ChunkUploader模块里。2. 超大附件的分片策略与参数计算2.1 分片大小怎么定才合理分片大小不能拍脑袋它跟网络环境、服务器接收能力、并发数强相关。太大会导致单片传输时间过长、失败重试代价高太小会导致片数过多、MD5计算和请求次数爆炸。我常用的经验公式是分片大小 max(2MB, min(文件大小 / 1000, 10MB))但对于卫星视频这种大文件我实际更推荐固定分片策略文件大小推荐分片大小说明 1GB2MB加快MD5计算失败重试粒度小1GB ~ 5GB5MB平衡片数与传输效率 5GB10MB减少分片总数降低索引开销以4GB文件为例5MB分片大约是819片。如果并发数为3每片平均耗时2秒理论耗时约9分钟这在军工内网场景下是可接受的。2.2 文件唯一标识分片续传的前提断点续传的核心是“识别同一文件”不能只靠文件名因为不同时间上传的同名文件太多。我在项目中采用的是“文件MD5部分采样 文件大小 最后修改时间”组合策略完整计算4GB文件MD5太耗时前端体验极差。具体做法是采样计算读取文件头256KB、中间256KB、尾部256KB连同文件大小拼接后计算MD5。虽然不能做到100%唯一但对99.9%的场景已经足够。关键代码如下function computeFileIdentity(file) { return new Promise((resolve, reject) { const blobSlice File.prototype.slice || File.prototype.mozSlice || File.prototype.webkitSlice; const chunkSize 256 * 1024; const chunks [ blobSlice.call(file, 0, chunkSize), blobSlice.call(file, Math.max(0, Math.floor(file.size / 2) - chunkSize / 2), Math.max(0, Math.floor(file.size / 2) chunkSize / 2)), blobSlice.call(file, Math.max(0, file.size - chunkSize), file.size) ]; const reader new FileReader(); let index 0; const md5 new MD5(); reader.onload function(e) { md5.append(e.target.result); index; if (index chunks.length) { readNext(); } else { md5.end(); resolve({ identity: md5.hex(), size: file.size, lastModified: file.lastModified }); } }; reader.onerror reject; function readNext() { reader.readAsArrayBuffer(chunks[index]); } readNext(); }); }注意MD5()这里是一个简化示意实际项目我推荐使用spark-md5的增量接口避免把整个分片数据一次性读入内存。2.3 并发数与内存控制的取舍很多人在做分片时只关心并发数忽略了浏览器内存压力。每个分片读取到内存后如果同时发起多个请求内存中会同时存在多个ArrayBuffer。4GB文件分片虽然不会一次性全读进来但10个并发同时各持5MB数据就是50MB内存占用加上页面其他资源很容易触发浏览器崩溃。我最终把并发数调成3同时在每个分片上传完成后立即释放引用。实测在国产化浏览器Chromium 76内核上稳定运行内存占用控制在200MB以内。3. 断点续传的后端接口设计与前端对接3.1 接口契约先行前端做断点续传离不开后端配合。我设计了一套最小可用的REST接口前端和后端都按照同一份契约开发接口方法作用/upload/initPOST告知后端文件名、大小、唯一标识后端初始化上传任务返回上传ID/upload/checkGET根据上传ID查询已上传分片索引列表/upload/chunkPOST上传单个分片携带上传ID和分片索引/upload/mergePOST所有分片上传完成后通知后端合并文件这套接口设计的关键点在于check接口决定了续传的起点chunk接口保证分片的独立性和可重试性merge接口是最后一公里的闸门。3.2 续传流程的完整闭环前端续传逻辑其实不复杂核心就是“先问后传”1. 计算文件唯一标识identity 2. 调用 /upload/check 查询已上传分片 3. 得到已上传索引数组 uploadedIndexes 4. 遍历全部分片跳过已上传的上传未上传的 5. 全部完成后调用 /upload/merge这里最容易踩的坑是后端check时不要只看分片文件是否存在必须核对分片大小和MD5。否则断点后恢复时可能因为之前写入了一部分坏数据导致后续分片全部白传。我在后端合并前加了一层“分片完整性校验”发现不一致就强制前端重传该分片。另一个容易被忽略的细节秒传的隐藏逻辑。如果/upload/check返回的结果是“该文件已存在且完整”前端应该直接走/upload/merge完成秒传。这对军工行业重复上传卫星视频素材的场景太实用了同一条轨道数据可能被不同科室重复上传。3.3 跨浏览器兼容的关键处理军工内网的浏览器环境比较特殊很多还是老旧的国产化浏览器。我针对几个核心API做了兼容处理File.sliceFile.prototype.slice在不同内核有mozSlice和webkitSlice的旧前缀必须做兼容。FileReader老浏览器不支持readAsArrayBuffer需要降级用readAsBinaryString但要注意后者的性能差很多。Blob部分老内核不支持new Blob()我直接用slice出来的Blob对象不额外构造。XHR老内核不支持xhr.upload.onprogress只能用xhr.onprogress替代但拿不到上传进度只有下载响应进度。跨浏览器的核心经验是写一个兼容工具函数统一封装API业务层永远只调用封装后的方法不要在业务代码里到处判断浏览器类型。4. 实操过程中的故障实录与排查清单4.1 断点续传失效分片索引错位上线后第一个严重bug是续传后文件损坏。排查发现后端保存分片时用的是前端传的chunkIndex但并发上传时请求到达后端的顺序是乱的某分片先写入大块数据后面的请求覆盖了之前的偏移量导致数据错位。解决方案很简单后端不依赖请求到达顺序而是在/upload/merge时按照分片索引重新拼接。前端在上传分片时就带上chunkIndex后端暂存为独立临时文件合并时按索引排序拼接。这个改动让我意识到断点续传不能用“追加写”模式必须用“索引写”模式否则并发和重试永远有风险。4.2 内存泄漏MD5计算拖垮页面最初用spark-md5计算4GB文件MD5时因为一次性把整个文件读进FileReader浏览器直接卡死。排查后改用增量计算每读取一个分片就spark.append()并且读取完立即释放分片引用。如果文件特别大建议把MD5计算放到Web Worker中避免阻塞主线程。我在项目中为了减少改造量先用的是采样计算内网实测一个4GB视频计算耗时为3~5秒完全可接受就没有上Worker。但如果你们的文件有几十GBWorker是必须的。4.3 网络中断后的恢复时间过长这个问题出在重试策略上。最初遇断网就无限重试恢复后所有分片重新排队用户体验很差。后来我加了“指数退避”策略重试间隔 min(30秒, 基础间隔 * 2^(重试次数))同时利用/upload/check接口在恢复后立刻查询已上传分片跳过已完成的部分。实测恢复后续传速度比全量重传快3倍以上。4.4 常见问题速查表现象可能原因解决方案上传进度条不动并发数为1且分片过大增大并发数减小分片大小进度条跳变分片大小不均匀确保最后一片按剩余大小处理不要统一按固定大小切片续传后文件打不开分片拼接顺序错乱后端按分片索引排序拼接大数据文件上传导致浏览器崩溃分片数据未释放上传完成后置空变量降低并发数老内核浏览器不触发uploadProgress不支持该API降级使用xhr.onprogress5. 从一次数据事故反思校验机制的必须性上线后某周有用户反馈某段卫星视频在播放器内花屏。排查后发现该文件在传输过程中有一个分片发生了静默损坏。文件大小没变MD5也能对上某几个分片但拼接后数据就是错的。问题出在我当时只对分片做了大小校验没做内容校验。于是后端在/upload/check和/upload/merge两处都加了分片MD5校验前端在合并前后端会重算整个合并文件的MD5与前端提交的identity比对不一致则强制前端重传全部分片。虽然多了一些计算开销但军工场景对数据可靠性要求极高内容校验不能省。如果你们对传输可靠性要求不高可以只做大小校验但如果数据错了会造成严重后果务必加上内容级校验。另外值得一说的是分片大小、并发数、校验策略这些参数不要写死在代码里。我在项目中把它们全部抽成了配置项后端也能远程下发这样在不同链路环境下可以灵活调优不用反复发版。6. 一次真实的上线排障记录最后一次联调我们模拟了从某基地到中心机房的跨地域传输4.7GB卫星视频网络架构经过两跳三层交换机。第一次跑全量上传耗时约18分钟其中分片计算约5秒实际传输约17分钟。完成后核对文件MD5与源文件一致播放正常说明整个链路改造成功。但这过程中也暴露了一个问题中途故意断开网络业务侧检测到断网后没有自动暂停未完成的分片请求而是等XHR超时。超时时间默认120秒导致恢复网络后有多个分片还在等待超时回调占用了并发窗口。后来我在网络断开时手动调用xhr.abort()立即释放所有未完成请求重新排队。这个改动让我意识到断点续传不仅要处理“上传中断”还要处理“网络状态切换”后者对体验的影响更大。如果你正在做类似的超大附件上传需求我的建议是不要一上来就追求完美先跑通最小闭环分片上传续传再逐步加并发控制和校验。先把主体跑起来再加固比一次性大而全的方案更稳妥。
