在前端面试里如果问到大文件上传几乎每个人都能背出那套标准八股文用Blob.slice对文件进行物理切片然后用Promise.all并发上传最后调一个后端的合并接口。听起来无懈可击对吧但在真实的业务现场当你的代码跑在高铁上的弱网环境、或是丢包率极高的星巴克公用Wi-Fi下时这套标准答案往往会引发一场场线上灾难。上传进度条会在最后卡死浏览器页签会突然白屏崩溃甚至后端网关会直接把你判定为恶意攻击而拉黑。为什么看似完美的逻辑一碰到复杂的物理网络就会碎成渣接下来咱们聊一聊这个话题常规切片上传有什么问题大多数网上的教程教你的都是纯粹的玩具级代码。它们最大的问题在于完全无视了浏览器底层的并发限制和物理网络的脆弱性。当你对一个2GB的大文件切出了100个分片然后大手一挥直接用Promise.all把100个请求同时砸向后端时灾难就开始了首先现代浏览器对同一个域名的 TCP 并发连接数是有严格限制的通常是6个。你发出的100个请求会在浏览器底层网络栈里排起长队互相挤占极其有限的带宽导致大量请求在排队阶段就直接报超时错。其次在弱网环境下只要其中有两三个分片因为丢包而上传失败整个Promise.all就会直接进入reject状态。前面辛辛苦苦传完的97个分片状态瞬间丢失用户只能被迫从头开始这种体验简直是毁灭性的。没有并发控制、没有容错重试、没有状态持久化的切片上传就是一场灾难的开始。简单实现原生并发队列与退回重试真正能上生产环境的上传模块绝对不应该依赖花里胡哨的第三方大件库而是要老老实实地用底层的JavaScript去精准接管整个上传生命周期。我们不需要引入庞大的状态机。利用极简的异步任务队列配合递归控制就能在纯原生的Web API下实现带错误重试、精准并发控制的上传逻辑// 大文件切片并发上传队列控制interfaceChunkTask{chunk:Blob;index:number;retryCount:number;}exportasyncfunctionuploadChunksWithControl(tasks:ChunkTask[],maxConcurrency4,// 极其克制的并发数保护网络带宽maxRetries3// 弱网环境的重试次数):Promisevoid{letcurrentIndex0;letactiveCount0;lethasErrorfalse;returnnewPromise((resolve,reject){constenqueueasync(){// 如果存在有不可恢复的重试耗尽或者任务已经发完直接退出if(hasError||currentIndextasks.length){if(activeCount0!hasError)resolve();return;}// 获取当前要处理的任务并移动指针consttasktasks[currentIndex];activeCount;try{awaituploadSingleChunk(task);}catch(err){// 如果遇到网络抖动不报错而是进行静默重试if(task.retryCountmaxRetries){console.warn(分片${task.index}上传失败正在进行第${task.retryCount1}次重试...);task.retryCount;// 将失败任务重新插回队列末尾排队tasks.push(task);}else{hasErrortrue;reject(newError(分片${task.index}弱网重试${maxRetries}次后彻底失败));return;// 掐断后续上传避免资源浪费}}finally{activeCount--;enqueue();// 递归触发下一个空闲插槽的任务}};// 初始化时填充并发池启动指定数量的任务for(leti0;imaxConcurrencyitasks.length;i){enqueue();}});}// 模拟单个分片的独立网络请求asyncfunctionuploadSingleChunk(task:ChunkTask):Promisevoid{constformDatanewFormData();formData.append(file,task.chunk);formData.append(index,task.index.toString());constresawaitfetch(/api/upload-chunk,{method:POST,body:formData,});if(!res.ok)thrownewError(Network Error);}这段代码没有任何魔法。它通过activeCount永远将并发请求死死卡在阈值比如4以内。同时某个分片因为弱网失败了不仅不会导致全盘崩溃反而会被打回队列重新排队。这种退回策略是移动端弱网环境下保障上传成功率的前提。那些在真机上才会暴露的坑哪怕你写出了上面 的并发队列一旦放到真实的业务线上去跑大文件依然会碰到只有在深水区才会暴露的死角。这些才是拉开架构师和普通开发差距的地方。页面静默中崩溃很多新手在切片时喜欢把所有的Blob对象转成ArrayBuffer或者Base64存在一个巨大无比的数组里。如果用户上传的是一个5GB的高清视频这个低级操作会瞬间撑爆浏览器的堆内存导致页面卡死或直接白屏抛出OOM。所以咱们 必须清楚一点File.slice()产生的只是文件物理内存的指针引用而不是真实的数据拷贝。在真实网络请求发生之前绝对不要去调用任何FileReader方法读取内容。只有在发请求的瞬间才将引用丢进FormData。计算文件哈希时尽量避免主线程卡死为了实现断点续传和秒传校验我们需要用文件的哈希值如MD5或SHA-256作为全局唯一标识。但对于几个GB的文件如果用纯JavaScript在主线程全量计算哈希页面会整整卡死几十秒任何按钮交互都会瘫痪的。所以咱们对于几十兆以上的大文件必须丢进Web Worker中进行分块异步计算。更高级的工程做法是抽样哈希仅抽取文件头部的2MB、尾部的2MB加上中间若干个小片段拼接这能在保证冲突率极低的前提下把计算时间从几十秒压缩到几百毫秒。状态持久化移动端浏览器极其不靠谱用户切出去回个微信你的上传页面可能就被系统杀掉后台了。等用户重新点开页面内存里的分片状态全部丢失只能咬牙从头再传。如果引入IndexedDB或localStorage作为本地状态机时每成功上传一个切片就向本地数据库持久化写入一条记录。用户刷新页面后通过哈希比对本地记录直接过滤掉已经成功的切片数组无缝接管中断的上传任务。大文件断点续传架构图建议收藏在大厂的日常业务里很多听起来高大上的架构优化其实底层的逻辑非常朴素的。我们要对抗的从来不是多么深奥的算法机制而是浏览器可怜的并发限制、脆弱的物理网络以及设备的物理内存上限。前端工程师不仅要会写代码更要懂得对底层的物理极限保持敬畏。当你能把一个巨大无比的文件在网速只有50KB/s并且频繁断网的恶劣环境下稳稳当当、不漏一片地送到服务器时你在这个圈子才算是真正摸到了前端工程的门道。好了今天就分享到这里