WebUploader改造实战：大文件断点续传插件设计与实现

接手这个需求时，我盯着需求文档看了很久——卫星视频、超大附件、跨浏览器、断点续传，四个词组合在一起，注定了这个上传模块不可能是一个普通的多文件组件。文件单个体量动辄几十GB，使用环境是浏览器版本参差不齐的内网，网络链路时不时给你来个中断，而用户的要求只有一句话：把文件安全、完整、可续传地传上去。默认的WebUploader在这种场景下基本是扛不住的，必须动手改造。

这个任务里有个容易被忽略的关键点：它不只是“把分片上传跑通”，而是要把WebUploader从一个“上传组件”改造成一个真正适配军工级数据回传场景的“断点续传插件”。接下来我会把整个改造思路、关键技术实现、踩过的坑，以及最终沉淀出来的插件写法，完整拆给大家。如果你手里也有类似的大文件、多浏览器、不稳定网络的场景，这篇内容可以直接当参考方案用。

1. 场景破题：这个需求到底难在哪

1.1 卫星视频上传场景的三个硬约束

先说清楚业务现场到底是什么样的。某军工项目里，卫星地面站会持续产出高清视频数据，这些文件需要从一线站点回传到中心机房做分析和归档。单个文件几十GB是常态，部分原始格式甚至能到百GB级别。这个场景天然带着三个硬约束，每一项都会把普通上传方案逼到墙角。

第一，文件体量极大。几十GB的文件如果走整文件上传，要么被网关直接拦掉，要么传一半断了就得从头再来，几乎不可能成功。第二，网络条件不理想。这个“不理想”不是普通办公网那种偶尔抖动，而是会真实出现的长时间中断、IP切换、带宽波动，上传任务经常挂在半路。第三，浏览器环境混乱。使用方不是统一配发的PC，现场既有新版本的Chrome和Edge，也有IE11，还有一些看似双核、实际上Chromium内核版本很老的安全浏览器。我们没法强制每个人都装同一个浏览器。

这三个约束叠加在一起，意味着方案必须同时解决“大文件拆分”“中断后能从断点继续”“旧浏览器也能跑”这三个问题。市面上能用的成熟组件里，WebUploader是底子最好、最值得改造的一个，但它默认状态离可用还有不小距离。

1.2 WebUploader默认能力的先天短板

WebUploader本身是一个经典的开源上传组件，核心价值在于它内置了HTML5、Flash、HTML4三种运行时，能根据浏览器能力自动降级，而且自带分片上传（chunked）、并发控制（threads）、MD5计算这些基础能力。单看功能列表，它好像已经覆盖了我们的大部分需求。但真正放到军工场景里一测，三个短板的致命程度立刻暴露出来。

短板之一是“分片上传不等于断点续传”。WebUploader的分片能力只解决“文件被切碎、分批发出去”的问题，一旦页面刷新、浏览器关闭或者队列被清空，已经传过的分片记录就全部丢失，重新选择文件后要从第一个分片重新传。“上传中断恢复”这个能力，组件默认是没有的，必须靠二次开发来实现。

短板之二是它对超大文件的处理不够健壮。文件越大，生成MD5的时间越长，如果实现得粗糙，几十GB的文件会在hash阶段把浏览器卡死。另外，分片大小是写死的，不同网络环境下灵活性不足，遇到网关限制请求体大小的场景就直接失败。

短板之三是跨浏览器能力的“默认支持”和“可用”之间差距很远。老版本IE下会退化到Flash运行时，而Flash对分片和并发支持都不完整，更别指望断点续传。如果我们不干预，用户拿老浏览器打开页面，看到的现象就是“上传到一半就断了，而且没法续”。

1.3 改造目标与技术边界

所以我给这个改造定了个清晰目标：在不重写WebUploader传输内核的前提下，利用它的插件机制和事件机制，给它补上“文件指纹”“已传分片探测”“断点恢复”“跨浏览器降级策略”这四块能力，最终封装成一个独立的上传插件，外部调用方只需要关心进度和结果，不需要关心内部分片逻辑。

这里也必须明确技术边界。有些东西不是前端能解决的：端到端的链路加密、服务端存储策略、合并分片后的一致性校验，这些需要后端配合。前端能做到的最重要的事，是把分片和状态管理得足够清楚，让任何时刻的失败都可以被精确恢复。我一贯的认知是：断点续传从来不是前端单方面的功能，而是前后端各承担一半责任。

2. 整体方案设计：分片、续传、兼容三位一体

2.1 分片上传的基本模型与分片大小选择

分片上传的核心模型其实一句话就能说清：把一个大文件按固定大小切成N块，一块一块传，服务端先存分片，全部到位后再合并出完整文件。这个模型的好处是，任何一个分片失败只需要重传那一片，网络利用率高，同时还能通过并发把传输速度提起来。

分片大小的选择是这个模型里最需要权衡的参数。它不是越大越好，也不是越小越好。我的经验是：带宽充足的内网环境，10MB左右比较均衡；如果网络网关存在请求体大小限制或者链路不稳定，压到2MB到5MB更稳妥。为什么？分片太大会放大单次失败的成本，重传一个20MB的分片和重传一个5MB的分片，耗时差距明显。分片太小则意味着请求数量暴涨，比如一个30GB文件切成1MB片，就是3万个请求，握手和响应开销会拖慢整体速度，服务端压力也大。

我建议在插件里把分片大小做成可配置项，默认10MB，同时提供一个自动探测机制：首次上传时如果发现连续多个分片失败且返回码与请求体大小相关，就自动把分片大小减半重试。这个机制在真实项目中救过我们很多次，因为很多内网网关的限制你根本不知道，只有实际发请求才能试出来。

2.2 断点续传的核心逻辑：先探后传

断点续传能做到，依赖的是一句非常朴素的话：在开始传任何数据之前，先问服务端“这个文件之前传过哪些分片”，然后只传缺失的那部分。为了能向服务端提问，前端必须先给文件生成一个唯一标识，也就是文件指纹。最可靠的方式是对文件内容计算MD5，因为只要内容相同，无论来自哪台机器、什么时间，MD5都一致。

整体流程是四步。第一步，文件加入队列后先做切片读流，增量计算MD5，生成fileKey。第二步，调服务端查询接口，传入fileKey，服务端返回两个信息：这个文件是否已经完整存在（秒传场景），以及当前已收到哪些分片。第三步，如果文件完整存在，直接跳过所有上传，提示秒传成功。第四步，如果只是部分存在，就只把缺失的分片加入传输队列，那些已经传过的分片走一个轻量验证通道直接标记成功。所有分片完成后，前端调合并接口让服务端把所有分片拼回完整文件。

这套逻辑天然支持断点续传：只要服务端没有把临时分片删掉，用户刷新页面后重新拖入同一个文件，重新计算MD5后得到的fileKey不变，探到的已传分片也还在，于是就能从断点继续。这里有个工程上的重点：MD5计算需要支持中途恢复，否则几十GB文件每次刷新都重新算一遍完整MD5，体验会很差。后面第3节我会给出具体实现。

2.3 跨浏览器兼容的降级策略

跨浏览器这件事，在设计阶段就要定好策略，而不是等用户报问题再打补丁。我的策略是“分级支持”：把浏览器分成三档，每档有明确的可用能力边界。

第一档是主流现代浏览器，包括Chrome 60以上、Edge、Firefox 60以上、IE11。这些浏览器支持完整的File API和Blob.slice，走HTML5运行时，分片、断点续传、MD5全部可用。第二档是IE9和IE10，这些环境WebUploader会退回Flash运行时，Flash下虽然能做分片，但稳定性差，而且Flash生命周期已经走到尾声，不值得为了它保留复杂逻辑，我的做法是降级为整文件上传，关闭分片和续传，保证“能传上去”是第一优先级。第三档是HTML4模式，常见于某些极其老旧环境的极低概率场景，此时连File API都不可用，只保留原始表单上传能力。

设计降级策略时有个容易犯的错误：把所有浏览器都按照最高能力去设计，然后寄希望于组件自动降级。结果往往是老浏览器确实降级了，但很多高级功能逻辑还在跑，明明没有File对象却去读file.size，整个页面报错。正确的做法是插件在初始化时先探测运行时类型，然后根据类型拉起不同的逻辑分支，没有File API的分支就不要创建MD5计算实例。

3. 核心改造实现：关键代码与技术细节

3.1 基于SparkMD5的文件指纹计算

文件指纹是整个断点续传方案的地基，指纹算错了，后面全乱。我使用的是SparkMD5库，它支持增量hash，意味着我们可以把文件切成小块，读一块算一块，而不是一次性把整个文件读进内存。这一点对几十GB文件至关重要，一次性读取直接内存溢出。

function computeFileMD5(file, chunkSize) { return new Promise((resolve, reject) => { const sliceFn = file.slice || file.mozSlice || file.webkitSlice; const spark = new SparkMD5.ArrayBuffer(); const totalChunks = Math.ceil(file.size / chunkSize); let current = 0; const reader = new FileReader(); reader.onload = function(e) { spark.append(e.target.result); current++; if (current < totalChunks) { loadNext(); } else { resolve(spark.end()); } }; reader.onerror = function() { reject(new Error('文件读取失败: ' + file.name)); }; function loadNext() { const start = current * chunkSize; const end = Math.min(start + chunkSize, file.size); reader.readAsArrayBuffer(sliceFn.call(file, start, end)); // 这里可以抛进度事件，更新界面上的hash计算进度条 } loadNext(); }); }

这里有个非常关键的类型细节：FileReader.readAsArrayBuffer得到的是ArrayBuffer，必须用SparkMD5.ArrayBuffer这个变体，如果用普通SparkMD5，append进去的类型不匹配，算出来的结果永远是错的。我见过不止一个项目在这个地方栽跟头，现象是每次计算的MD5都不同、续传永远续不上。

获得MD5之后，fileKey的生成规则我推荐用“文件名_文件大小_文件MD5”的拼接方式。文件名和大小用于直观展示和日志排查，MD5用于真正的内容唯一性判断。注意文件名里可能有特殊字符，拼到fileKey之前先做encodeURIComponent，否则后续路径拼接和参数传递会出各种奇奇怪怪的编码问题。

3.2 上传前探测：分片索引的查询与过滤

拿到fileKey后，接下来要做的就是交给服务端去判断。这里我设计三个接口，分别对应秒传判断、分片状态查询、合并请求，具体接口约定后面第4节会给全。

前端拿到服务端返回的“已上传分片索引数组”后，需要把它转成Set，方便在后续上传流程里O(1)判断每个分片是否需要重新传输。这个Set要挂在文件对象上，因为分片上传是异步并发的，回调里必须能回溯到当前分片属于哪个文件。

uploader.on('fileQueued', async function(file) { const md5 = await computeFileMD5(file.source, CHUNK_SIZE); const fileKey = encodeURIComponent(file.name) + '_' + file.size + '_' + md5; file.fileKey = fileKey; const checkRes = await fetch(`${API_BASE}/checkFile`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ fileKey }) }); const checkData = await checkRes.json(); if (checkData.complete === true) { // 服务端已有完整文件，直接秒传 uploader.removeFile(file, true); emit('fileSuccess', file.name); return; } // 记录缺失分片集合，后续上传时只传这些 const uploadedSet = new Set(checkData.uploadedChunks || []); file.uploadedSet = uploadedSet; file.totalChunks = Math.ceil(file.size / CHUNK_SIZE); // 界面进度条直接恢复到已上传比例 const donePercent = uploadedSet.size / file.totalChunks; emit('fileProgress', file.name, donePercent); });

这里有个实际业务里经常被忽略的点：服务端判断“已上传分片”时，不能只看文件名是否存在，必须校验分片大小和完整性。因为网络传输过程中可能出现分片长度缺失、内容损坏的情况，服务端如果只凭分片存在就返回“已存在”，会把损坏状态继承下来，最终合并出的文件静默损坏。所以服务端存分片时，要连同原始长度一起记录，前端探测接口返回前必须校验长度一致。

3.3 并发控制与内存规避

并发分片数需要谨慎设置。WebUploader的threads参数控制同时发送的请求数，这个值不是越大越好。我们的目标是吃掉带宽，而不是打爆服务端或者让网关限流。内网环境下我通常设为3到5，公网或专线不稳定的场景设为2。为什么不能设置成10以上？因为分片上传的瓶颈经常不是带宽，而是网关的连接数限制和请求处理能力，并发过高会触发大量TCP连接排队，反而把延迟拉高。

内存方面要重点说一个很多人的误区：FileReader读取分片是异步流式的，本来不会造成内存暴涨，但如果代码里为了“获取进度”把每个分片的ArrayBuffer都存到全局数组里，那几十GB文件的上传进程会把浏览器内存直接拉爆。我见过真实案例，一个30GB的文件，分片大小5MB，某同事把6000个分片的ArrayBuffer都暂存在内存里等待统一发送，浏览器直接崩溃。正确做法是每个分片的ArrayBuffer在reader.onload里append进SparkMD5之后立即释放引用，分片数据只存在于当前调用栈，不要让它在闭包或全局变量里长期存活。

并发控制还有一个隐含收益：它天然限制了同时读文件的个数。WebUploader对队列里的多个大文件会同时开多个读取流，如果不做限制，几个几十GB的文件一起算MD5，CPU和内存都会出问题。我建议插件内部维护一个全局信号量，同时只允许一个文件在算MD5，算完再算下一个，上传阶段再交给WebUploader的threads控制并发。

4. 实战演练：接入一个可用的断点续传流程

4.1 改造WebUploader初始化参数

初始化是整个改造的第一个入口。直接给一份我实际项目中沉淀下来的核心配置，不是官方demo那种浅层用法。

const CHUNK_SIZE = 10 * 1024 * 1024; const API_BASE = '/api/video/upload'; const uploader = WebUploader.create({ swf: '/static/swf/Uploader.swf', server: `${API_BASE}/uploadChunk`, pick: '#picker', accept: { title: '卫星视频', extensions: 'mp4,mov,avi,mxf', mimeTypes: 'video/*' }, chunked: true, chunkSize: CHUNK_SIZE, threads: 3, fileVal: 'chunk', auto: false, duplicate: true, formData: { source: 'satellite-video' } });

几个参数值得单独解释。chunked必须为true，这是分片前提。chunkSize就是前面反复权衡过的分片大小，实际使用中我会让它支持运行时动态调整。fileVal指定分片数据在表单里的字段名，后端那边必须对应收这个字段。threads是并发数，军工内网通常3就够了，太多反而容易撞到网闸或防火墙的并发限制。duplicate: true必须开，否则同一个文件刷新后重新选择会被组件当成重复文件拦掉，断点续传就是想续也续不上。

还有个细节：WebUploader默认会为相同文件名的重复添加打上标记，而续传场景恰恰需要重复添加同一个文件。所以如果你发现刷新页面后重新选择同一路径文件没反应，先检查duplicate配置。

4.2 服务端配套接口设计

前端改造再好，服务端接口设计跟不上就是白搭。断点续传最少需要四个接口，我把它们列成一张表，字段约定必须前后端一起定，这个表可以直接拿给后端同事当设计文档用。

这里重点说下“为什么需要checkChunk这个轻量验证接口”而不是让前端直接把已存在的分片从队列里删掉。WebUploader的分片调度逻辑在内部维护，插件外部很难精确删除某一个分片，强行操作很容易破坏队列状态。所以我的做法是：已存在的分片照常进入发送流程，但在uploadBeforeSend阶段拦截，把该分片的请求目标改成checkChunk接口。这样服务端返回“已存在”，WebUploader认为这个分片上传成功，继续走后续流程，而实际上没有传输任何视频数据。这个思路实现简单、不动WebUploader内部队列，是最稳的打法。

uploader.on('uploadBeforeSend', function(block, data) { const file = block.file; data.fileKey = file.fileKey; data.index = block.chunk; data.total = block.chunks; data.originalName = encodeURIComponent(file.name); // 如果该分片之前已经上传过，就改走轻量验证接口 if (file.uploadedSet && file.uploadedSet.has(block.chunk)) { block.server = `${API_BASE}/checkChunk`; } });

这段代码是整个断点续传改造里最精巧的地方，它把“分片跳过”变成了“分片验证”，不仅避免了数据重传，还保持了上传队列的状态一致性。block.server如果在你手里的WebUploader版本里不起作用，替代方案是在WebUploader实例上临时改options.server，但并发场景下要小心其他分片也被带偏，所以我还是建议用block级别的目标地址覆盖。

4.3 合并触发与收尾处理

所有分片都传完后，前端需要感知到这个状态并通知服务端合并。WebUploader的uploadComplete事件会在一个文件的所有分片流程结束时触发，但它触发时既不区分分片是否走的是checkChunk，也不保证合并已经在服务端执行，所以合并动作要我们自己发。

我建议在文件对象上维护一个“完成分片计数”，在每次uploadSuccess里累加，当计数等于totalChunks时发起合并请求。注意不要简单地在uploadComplete里无脑调merge，因为如果有分片走了checkChunk，它也会触发uploadComplete，但那时其他分片可能还没传完，直接merge会拿到残缺文件。

uploader.on('uploadSuccess', async function(file) { file.completedCount = (file.completedCount || 0) + 1; if (file.completedCount === file.totalChunks) { const mergeRes = await fetch(`${API_BASE}/merge`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ fileKey: file.fileKey, fileName: encodeURIComponent(file.name), totalChunks: file.totalChunks }) }); const mergeData = await mergeRes.json(); if (mergeData.code === 0) { emit('fileSuccess', file.name, mergeData.fileUrl); } else { emit('fileError', file.name, '合并失败'); } } });

合并完后还有一件非常重要的事：从服务端归档目录把合并后的视频文件移到正式存储区，同时清理临时分片目录。如果不清理，断点续传虽然能用，但临时目录会越积越大，最后磁盘被半截文件塞满。清理策略可以交给服务端定，比如超过24小时未合并的任务自动清理，但前端在成功合并后通知服务端主动清理是省事又及时的做法。

4.4 插件化封装：对外暴露最小可用接口

标题里强调“插件”，最后一步就是把所有逻辑收拢成一个可复用的封装。我不希望业务页面去关心WebUploader的细节，所以对外只暴露一个干净的类。

class SatelliteUploader { constructor(container, options) { this.options = Object.assign({ chunkSize: 10 * 1024 * 1024, threads: 3, apiBase: '/api/video/upload' }, options); this._init(); } _init() { // 创建WebUploader实例，绑定所有内部事件 // 对外只转发成功、错误、进度三种事件 } choose() { // 触发文件选择对话框 } start() { this.uploader.upload(); } pause() { this.uploader.stop(true); } onProgress(callback) { // 对外进度回调 } onSuccess(callback) { // 对外成功回调 } onError(callback) { // 对外错误回调 } destroy() { this.uploader.destroy(); } }

封装成这个形态以后，业务侧接入的成本非常低，三行代码就能完成一个支持超大文件断点续传的上传入口。而且后续如果WebUploader出现不可修复的问题，替换底层实现时也只需要改这个类内部，对外调用方完全无感。这种面向接口的封装方式，是我在几个类似项目里一直坚持的做法。

5. 踩坑实录与排查思路

5.1 跨浏览器兼容的典型问题

我们在一线单位实际推进时，最头疼的往往不是核心逻辑，而是那些“理论上该支持”的浏览器真机表现。有一次某现场反馈“用某国产安全浏览器传文件，进度条不走”，排查半天发现那个看起来是双核的浏览器，实际内核版本停在Chromium 55，带webkit前缀的File.slice方法倒是能用，但FileReader.readAsArrayBuffer性能异常差，10MB分片要卡十几秒。

解决办法是把分片大小动态降下来，检测到浏览器满足“存在FileReader但readAsArrayBuffer性能差”的条件时，强制退到5MB分片。更彻底的做法是给这类浏览器走Flash降级，但在现在的浏览器生态里，Flash也不再可靠。所以我的最终策略是：插件启动时先做一遍能力探测，用一段非常小的测试文件实测slice和readAsArrayBuffer是否正常，不正常就直接关闭分片，退化为整文件上传，宁可不续传也不能卡死页面。

IE9和IE10的情况更特殊。IE9完全没有File API，只能走Flash；IE10的File API也不完整，slice方法存在但有时行为异常。针对这两个版本，我们明确在UI上提示“当前浏览器不支持断点续传，请使用Chrome或Edge获得完整体验”，同时保留整文件上传通道保证业务不中断。我认为在军工这类严肃场景里，明确告知能力边界比默默降级更好，用户知道当前状态下能不能断点续传，比上传到一半才发现断了要友善得多。

5.2 大文件MD5计算卡顿与恢复

MD5计算卡到浏览器假死，这个是几乎每个做超大文件上传的人都绕不过去的坑。原因很直接：如果一次性readAsArrayBuffer读整个几十GB文件，浏览器直接内存溢出，哪怕不溢出，读取过程也会阻塞主线程，表现为页面完全无法操作。

解决方案除了前面说的增量读取，还有一个细节：读取切片时用requestIdleCallback或者setTimeout把切片调度打散，避免连续占用主线程。另一个容易被忽略的问题是进度渲染的频率。算MD5时如果把每个分片的进度都同步到DOM上，DOM频繁更新照样卡死。我的做法是用一个节流函数，至少500毫秒才刷新一次进度显示，计算本身完全在数据流里跑，不依赖UI刷新。

对于“刷新页面后是否重新计算完整MD5”这个问题，我最后采用的方案是分级缓存：文件信息（文件名、大小、修改时间、MD5）写入localStorage，刷新后先按“文件名+大小”做一次快速匹配，如果匹配到就直接沿用缓存的MD5；匹配不到再完整计算。因为断点续传的前提是同一个文件、同一路径、大小不变，快速匹配的成功率很高。只有极少数情况需要重新完整hash，这样用户体验好很多。

5.3 断点续传失效的常见排查思路

断点续传失效时，现象往往是“刷新页面后重新选文件，又从0%开始传”。我把这类问题整理成一张速查表，排查时按顺序走就行。

最常踩的坑其实是“MD5计算完成前用户就已经点了开始上传”。因为计算几十GB文件的MD5要几分钟，这期间如果用户点了“开始”，WebUploader已经按未知fileKey把分片发出去了，等MD5算完，那边的分片又对不上号。这个问题的根治方式是：在MD5计算完成之前，禁止开始上传按钮，或者更彻底一点，在插件内部把开始动作先放进等待队列，MD5计算完成并完成探查后再真正放行。

5.4 安全与审计细节的补充

军工行业的项目对审计和安全的要求比普通项目高得多。我们改造上传插件时，同步做了三件事。第一，所有分片接口都要求携带可追溯的用户凭证，不能只依赖前端传一个用户ID，要由服务端从会话中解析，分片落盘时把上传者、时间、来源IP、文件标识一并写入审计日志。第二，文件扩展名和MIME类型不能只在前端做白名单，因为前端白名单可以被绕过，服务端必须根据文件头或魔数校验真实类型。卫星视频常见的MP4、MXF、MOV都有明确的文件头特征，服务端可以解析前几百字节做判断。第三，分片合并后要做最终校验，比对文件总大小是否等于各分片大小之和，并重新计算一次MD5与前端提交的MD5做比对，不一致则判定上传失败，整条任务进入重传队列。

这些安全措施初看会增加开发量，但在这个领域里属于出厂必须。我始终认为，上传插件不能只追求“传得快”，还要保证“传得对、传得可追溯”，尤其是当上传的内容是卫星视频这类高价值、保密等级高的数据时，这个原则更是铁律。

5.5 网关与超时类故障的兼容处理

实际运行中另一类高频问题来自网络设备和网关配置。某站点反馈“分片上传到一半就全部失败”，抓包看是TCP连接被重置，进一步排查发现该站点的网络安全设备把超过2MB的POST请求当作异常流量处理了。这个问题从代码上很难预判，只能通过“连续分片失败时自动减小分片大小并重试”的策略来兜底。

我们实现的兜底逻辑是：同一个文件连续3个分片上传失败，自动把分片大小从10MB降到5MB，再失败就降到2MB，如果2MB还失败，则暂停该文件并上报明确错误。这个策略在和现场网安的同事确认后，基本能覆盖“网关限制请求体大小”的绝大多数场景。同时，前端的超时设置也要注意：WebUploader默认超时并不总是适合大分片，服务端处理一个10MB分片可能需要几秒，加上排队时间可能超过10秒，建议把timeout调大到120秒，已经在生产环境验证过这个值是安全的。

还有一类问题容易被忽略：浏览器与服务端之间的Nginx或接入层超时配置。默认的proxy_read_timeout通常是60秒，如果分片较大、服务端落盘较慢，或遇到磁盘IO高峰期，单分片处理时间超过60秒就会被网关掐断。这种情况下前端重复重试也没用，必须同步优化服务端接口处理速度和网关超时配置，两边一起改才能根治。我踩过这次坑之后，就把“排查链路超时配置”列入了联调必查清单，并发团队每个人都会跟着过一遍。

真正把WebUploader改成能扛几十GB卫星视频断点续传的插件之后，我最大的体会是：很多方案在PPT上看着成立，到了真实的现场环境，老浏览器、奇怪的网关、不稳定的专线，每一样都可能是压垮方案的稻草。这个项目里真正帮上忙的，不是某个花哨的技术栈，而是“先探后传”的朴素逻辑、分片大小的动态自适应、以及前后端清晰的接口契约。如果你也要动类似的改造，我的建议很简单：先把需求里的网络现状摸清楚，再定分片策略和降级方案；先让断点续传跑通一个分片级的最小闭环，再考虑并发、限流和美化。这套路不惊艳，但真能落地。