在数据平台这一行摸爬滚打久了“上传”两个字真的能让人血压升高。尤其是我前阵子接手的一个内部业务系统动不动就要往服务器送几个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对象切片然后循环发起请求吗但等把需求列完整你会发现要自己从头处理的东西太多了文件选择、多选、拖拽、目录上传、队列管理、文件状态机、进度统计、重试机制、重复文件处理……这些交互细节极其琐碎