在数据平台这一行摸爬滚打久了，“上传”两个字真的能让人血压升高。尤其是我前阵子接手的一个内部业务系统，动不动就要往服务器送几个GB的卫星视频文件。这个文件体量，放在普通互联网产品里已经很少见了，放在军工、航测这类数据管控严格的内网环境里，更是把问题无限放大：网络中断要重传、浏览器不兼容要罢工、网关还有体积限制。折腾了一圈，最后我把百度开源的WebUploader从犄角旮旯里翻出来，用JS重新改造了一版，做成了一套支持跨浏览器、超大附件、分片断点续传的上传插件。这篇文章就把我整个过程中的需求拆解、方案选型、代码实现和踩坑记录全盘写出来。
先说结论：WebUploader这个老组件本身仍然值得用，但别指望开箱即用，关键的分片调度、续传状态管理、跨浏览器能力探测，都需要从外面写一套JS逻辑把它包住。改造完之后，文件选择、拖拽上传、队列管理这些通用交互继续交给WebUploader，而真正决定“能不能传上去”的分片、续传、校验逻辑，全部掌握在我们自己手里。下面按我实际推进项目的顺序来聊。
1. 需求先拆清：卫星视频这类超大附件到底难在哪
很多人一听到“上传大文件”，直觉反应就是前端加个进度条、后端调大一下请求体限制，完事。但等文件真到了GB级别，尤其面对的是卫星视频这种高价值、高可靠性要求的数据时，问题会沿着技术链一层层暴露出来。
1.1 为什么2GB的视频不能直接整包传
卫星视频和普通录像不是一个量级的东西，我这边遇到的原始文件大小普遍在几个GB到几十个GB之间。表面上看，前端拿到一个File对象，用FormData丢给后端，似乎也没什么问题，但实际操作中至少会撞上三道墙。
第一道是网关限制。内网环境虽然没有公网那种严格的WAF，但Nginx、API网关、后端容器tomcat这些中间件都有自己的请求体上限，默认往往只有几十到几百MB，传一个2GB的文件大概率直接被拒。就算把这些中间件的限制全部调大，整个请求体要完整经过所有转发链路，任何一个环节超时都会导致全盘失败。
第二道是传输稳定性。大文件整包上传意味着失败成本是“0到100%”全量重来，一旦中间网络抖动或者后端连接断开，前面跑掉的时间全部作废。卫星视频这类文件传输往往还要跨部门、跨区域网络，链路质量并不像我们想象的那么可控，断点续传不是体验问题，而是能不能交付的问题。
第三道是并发和内存。整包上传时，前端把整个文件塞进一次请求，浏览器内存占用高不说，如果同时传多个文件，对客户端机器压力也非常大。分片上传则可以把长期占用的大请求，拆成一堆可以并行发出的小请求，任一片失败重试，都不会影响其他片，这才是大文件传输真正的工程化姿势。
把2GB文件拆成512个4MB的分片去传，看起来请求数量变多了，但每个请求小且独立，中间件限制很好绕过，网络波动最多影响单个分片，整体的可修复性是完全不一样的。
1.2 跨浏览器要求的潜台词
项目里对浏览器的要求，并不是“兼容一下Chrome和Firefox”这种常规说法，而是涵盖了老版本IE、360浏览器兼容模式、统信UOS上的国产浏览器、以及各种基于Chromium内核的定制浏览器。你永远无法预测一个偏远节点上的用户，究竟在用哪一年的浏览器打开这个系统。
这就带来一个很现实的问题：新一些的上传组件往往只在现代浏览器里经过测试，到了老内核环境不是功能异常就是压根不渲染。老的Flash方案倒是曾经能通吃，但Flash本身已经退出历史舞台，很多浏览器直接禁用了Flash插件，再指望它去兼容老环境也走不通。跨浏览器在上传场景里的本质，是你的前端代码必须做到“能力可探测、行为可降级”：支持File API的走HTML5分片上传，不支持的老内核浏览器至少能给出清晰提示，或者切换到一个最基础的表单上传通道。
另外，军工这类高安全要求的内网系统，通常不允许页面加载公网域名资源，所有JS、CSS、插件文件都必须本地化部署。这等于把很多“开箱即用”的第三方组件又挡在门外，国产化适配要求也意味着组件使用的加密算法、接口协议要尽量支持国密体系。这些因素叠加起来，选择一个稳定、可控、自己能看懂源码的上传基础组件，比选一个功能花哨但黑盒的库要重要得多。
1.3 为什么还要折腾WebUploader而不是自己写
说实话，我最早也想自己写一个上传控件，不就是拿File对象切片然后循环发起请求吗？但等把需求列完整，你会发现要自己从头处理的东西太多了：文件选择、多选、拖拽、目录上传、队列管理、文件状态机、进度统计、重试机制、重复文件处理……这些交互细节极其琐碎，
