群青色黑洞图纸这种东西，在汽车厂里的地位一直很特殊。几年前我们给研发部门做图纸管理系统，遇到的最大阻力不是功能设计，而是上传这一关——设计那边用的Catia数模，单个总成件动辄几百MB，整车数模更是几个GB上下，最初的网页上传功能传一半断掉、断掉重来、重来又超时，搞得设计同事直接在群里骂娘。更麻烦的是图纸本身就是核心资产，直接明文传，网管那边也一直提醒我们"内网抓包一旦被带走，查都没法查"。
所以后来我们整套上传模块重构，最后落地方案就是：基于百度WebUploader做分片断传，前端对每个分片做AES加密，后端按序解密合并。这套方案在局域网里跑了一年多，上传大图纸的稳定性上来了，抓包拿到的也只是一堆无法识别的密文，算是把"传得动"和"传得安全"两件事同时解决了。
这篇文章就把我们当时做完的完整实现拆开讲：从为什么选WebUploader、分片断传的机制，到密钥协商、分片加密、后端解密的完整链路，再到局域网实测踩过的几个大坑。适合汽车/制造业信息化工程师、前端开发，以及所有需要在大文件上传场景里加入加密控制的团队参考。
1. 汽车制造局域网里的图纸上传，到底难在哪
1.1 一个"小事"引发的连锁反应
先说几个真实数字。我们研发部门日常流转的图纸文件，单个零件模型通常在50MB到500MB之间，总成级数模可以到2GB以上。浏览器上传这种文件，最直接的问题不是技术不行，而是网络和用户预期之间的落差。
最初我们用的是原生XMLHttpRequest上传整文件，在千兆局域网里，理论上传一个2GB文件也就一分钟左右，但实际总会出状况：CAD软件占着内存导致前端卡顿、网络交换设备偶发丢包、办公室无线网络跳ping、后端Tomcat默认的请求体大小限制没调……任何一个环节卡一下，整文件上传就失败，用户只能重来。
做过文件系统的人都知道，大文件传输的第一原则就是"别把鸡蛋放一个篮子里"。把文件切成一个个几MB的分片，哪个分片失败就重传哪个，整体成功率会高一个数量级。这就是分片断传的核心价值。
1.2 为什么是WebUploader
当时团队也评估过几个方案，简单列一下：
| 方案 | 优势 | 劣势 |
|---|---|---|
| 原生File API + XMLHttpRequest | 无依赖、完全可控 | 分片、队列、重试、进度条全要自己写，开发量大 |
| Plupload | 功能全、支持多运行时 | 配置较重，后续维护一般 |
| OSS/S3直传 | 功能完善 | 需要外网和签名服务，纯局域网场景根本不适用 |
| WebUploader | 分片、MD5、并发控制、队列管理、UI组件齐全 | 项目更新停滞，但稳定够用 |
我们最终选WebUploader，核心原因很实际：它把大文件上传里最烦人的基础设施都做好了。分片大小自己定、并发数自己定、每个分片的状态由插件内部管理，还有内置的MD5计算和进度事件。尤其在那个时间点，团队人手紧张，与其从零写一套文件上传内核，不如把精力集中在我们真正要解决的问题上——分片加密和后台合并。
当然WebUploader这些年更新确实