Java大文件上传实战：分片、断点续传与秒传方案详解

汽车制造行业里，JAVA工程师迟早会碰到一个让人头疼的需求：设计部发来一个2.7GB的Catia整车数模，让你把它传到PLM系统里。第一次遇到这个需求，我下意识用最普通的MultipartFile方式接收，结果Tomcat直接OOM，前端请求超时，车间那边等着看图，整个项目群炸锅。后来我把这套大文件上传方案完整重构过一遍，从分片、断点续传、秒传到合并校验，中间踩了不少坑，也整理出了一套适合重工业制造场景的稳定做法。

这篇文章就围绕“汽车制造行业里JAVA怎么搞定大文件上传”来展开，把方案选型、前后端实现、性能优化和问题排查一次性讲透。内容不局限于汽车行业，模具、装备、半导体这类制造工厂的PLM/MES系统基本都能直接套用；如果你在准备面试，里面涉及的分片策略、内存治理、Redis断点续传设计也都是面试官常抠的细节。

1. 场景梳理与方案选型

1.1 汽车行业大文件上传的真实痛点

汽车制造行业的大文件，跟互联网行业说的“大文件”完全不是一个量级。互联网场景里一个视频几个GB，但内网带宽高、机器配置好；制造行业的特点是文件来源杂、网络环境差、生产系统老旧。

首先是文件类型杂。产品设计阶段有Catia、UG、Pro/E的整车数模，单个文件从几百MB到十几GB不等；工艺阶段有焊接参数表、装配动画、作业指导书PDF；质量阶段有零部件检测报告、生产线监控录像，一批多张照片加视频经常几个GB。这些文件统统要进PLM/PDM/MES系统归档。

其次是网络环境复杂。工厂内网看着是千兆，实际上办公区和车间之间隔着防火墙，多个厂区之间走专线，带宽可能只有几十兆。你在总部上传没事，在分公司上传一个大文件能传到一半断掉。车间现场还有老旧的Windows 7电脑配IE浏览器，前端能力受限。

然后是业务连续性要求。制造企业的文件是生产资料，设计数据丢了会导致产线停摆。上传过程不能因为网络抖动就前功尽弃，文件传完还要校验完整性。这些现实约束决定了：不能把大文件上传当成普通WEB功能来做，要当成一个完整的文件传输工程来做。

1.2 为什么常规的Servlet上传方案扛不住

很多人第一反应是：JAVA里用MultipartFile接收上传不就行了？Spring MVC里几行代码搞定。这套方案应付几十MB的小文件没问题，遇到GB级文件就全面崩溃。

第一个问题是Tomcat默认限制。Tomcat的maxPostSize默认是2MB，不修改配置，超过大小直接报错。把它调大到2GB，又会带来第二个问题：内存压力。Spring MVC默认把上传文件先读进内存，JVM堆不够就OutOfMemoryError。有人会说配个commons-fileupload的DiskFileItemFactory让它写临时文件，但HTTP请求体的接收过程依然是整体传输，没有进度反馈，没有断点续传，用户看到的就是“浏览器转了半小时，然后超时”。

第三个问题是无法中断续传。HTTP是短连接，TCP断了，这次请求就结束了。GB级文件在弱网环境下基本不可能一次传完，没有续传能力，用户只能重头再来。这种体验在工厂里会被一线工人骂到怀疑人生。

还有个隐患是代理和防火墙。一些工厂的网络安全设备对单请求大小有限制，超过1GB的HTTP请求体可能被安全策略直接拦掉。这就必须在前端把大文件切成小块，让每个请求体控制在安全阈值内。

1.3 技术路线对比与选型逻辑

行业里做过大文件上传的同行基本都知道，主流方案有这么几种。

FTP方式最老派：给用户一个FTP账号，文件先传到FTP服务器，再通过JAVA程序自动扫描、搬到业务系统里。优点是稳定、适合超大规模文件，缺点是用户体验割裂，用户不知道传完没有，而且FTP服务在企业内网有时会被安全策略限制。

客户端方式在国内制造业很流行，就是用Java Web Start或者独立客户端配合ActiveX控件，在上世纪遗留的IE环境里很常见。以前工厂里经常见到的“请使用IE浏览器，并检查浏览器的安全设置，不能装载NTKO大文件上传控件”，就是这类方案。它确实能解决IE环境的问题，但部署成本高、兼容性差、维护困难，现代浏览器根本不吃这一套。

浏览器原生分片上传才是当前的最优解。基于File API的slice方法把文件切成若干分片，每个分片独立HTTP请求上传到后端，后端负责接收和重组。这个方案的优势非常明显：单个请求体小，不会被代理拦截；上传进度可以精确到百分比；失败后只要重传失败的分片，不需要从头再来；前端用Web Worker处理文件读取，主线程不卡顿，体验顺滑。

我们最终选择的就是这条路：前端分片、后端合并、Redis记录上传状态、MD5做秒传和完整性校验。这套方案在汽车制造行业的多个系统里跑了两三年，稳定性和开发成本都表现不错。

2. 整体设计思路与关键流程

2.1 分片上传的完整业务流程

大文件上传不是只写一个Controller就能搞定的事，它是一个多接口配合的状态流程。我把整个流程拆成下面几个阶段。

首先是创建上传任务。前端拿文件的MD5、文件名、大小、分片大小，调用后端接口创建一个上传任务。后端生成一个全局唯一的taskId，往Redis里写一条记录，包含文件元信息和分片总数。这个taskId是后续所有操作的凭证。

然后是分片上传。前端按顺序把文件切片，每个分片带taskId和分片编号，调分片上传接口。后端每收到一个分片，写入临时文件，同时在Redis里记录该分片已上传。这个阶段是整个流程的核心，也是并发控制、断点续传最容易出问题的地方。

接着是分片合并。当Redis里记录的分片数等于分片总数，前端通知后端执行合并。后端把所有临时分片按顺序写入完整文件，做完MD5校验，把文件从临时目录移动到正式存储区，更新业务状态。

最后是文件落地。在制造企业里，文件传完不等于结束，还要把文件信息写入PLM/MES系统的业务表，关联物料编码、工单号等业务字段。这一步可以在合并完成后通过回调或者消息队列来触发，避免上传链路阻塞。

从接口设计角度看，最少需要四个接口：创建任务、上传分片、查询已上传分片、合并文件。这四个接口缺一不可，每个都有自己独立的失败场景要处理。

2.2 前端为什么必须配合Web Worker

前端这块最容易犯的错误，是直接在主线程里做文件切片和MD5计算。一个3GB的文件，用JavaScript在主线程算MD5，界面直接卡死，鼠标都点不动。这在车间用户那里是完全不能接受的。

Web Worker的价值就在这里。它能在后台线程处理文件读取和哈希计算，主线程只负责渲染进度条和交互。用户看到的是进度在走、界面流畅，Worker在后台闷头干活。

文件切片本身用File.prototype.slice就能做，浏览器原生支持，不需要额外库。切片大小的选择有个经验值：单片2MB到10MB之间比较合适。汽车行业的文件动辄几GB，切片太小请求数量太多，HTTP握手开销大；切片太大又失去了分片的意义，弱网下单片传输失败率会上升。

另外移动端的情况也值得注意，工程师有时候在车间拿着平板看图纸，移动网络弱，断点续传的诉求更强烈。前端Worker计算完MD5、完成切片后，把上传队列标记化，失败了就只重传失败的片，这个能力在移动网络下尤其好用。

2.3 后端设计要点：内存、磁盘和状态

后端设计要牢牢抓住三个问题：内存、磁盘和状态。

内存问题是最大杀手。接收分片的时候，如果直接把整个MultipartFile对象转成byte数组再写盘，内存必爆。正确做法是拿到InputStream直接流式写入磁盘，不能让文件内容完全驻留在堆内存。这个点在我后面第3.3节会给出具体代码。

磁盘问题关系到文件存哪里、怎么组织。制造企业的文件存储通常有专门的FTP或者共享存储，JAVA应用先写到本地临时目录，