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应用先写到本地临时目录，合并完再移动到共享目录。临时目录和正式目录要分清楚，用一个定时任务清理超过24小时未完成的分片垃圾，避免磁盘被占满。

状态问题直接决定断点续传能不能实现。上传任务的状态要放在Redis里，key用taskId，value用Hash结构存MD5、总分片数、已上传分片列表。为什么不存数据库？因为上传过程中状态变更非常频繁，每次写MySQL压力大、响应慢；Redis天然适合这种高频读写场景。合并完成后可以把状态迁移到MySQL做持久化记录，方便审计追溯。

3. 核心代码实现与实操细节

3.1 创建上传任务接口的实现

第一步是让前端把文件的MD5、大小、分片大小报上来，后端创建任务。

java复制@PostMapping("/upload/task")
public Result<String> createUploadTask(@RequestBody UploadTaskRequest request) {
    String fileMd5 = request.getFileMd5();
    long fileSize = request.getFileSize();
    int chunkSize = request.getChunkSize();
    String fileName = request.getFileName();
    String fileExt = fileName.substring(fileName.lastIndexOf(".") + 1);
    
    // 业务校验：文件扩展名是否在白名单内，防止上传恶意文件
    if (!isAllowedExt(fileExt)) {
        return Result.error("不支持的文件类型");
    }
    
    // 秒传逻辑：如果文件已存在且MD5一致，直接返回已存在的文件id
    FileRecord existRecord = fileRecordMapper.selectByMd5(fileMd5);
    if (existRecord != null) {
        return Result.success(existRecord.getFileId());
    }
    
    String taskId = UUID.randomUUID().toString().replace("-", "");
    int totalChunks = (int) Math.ceil((double) fileSize / chunkSize);
    
    // Redis保存任务状态
    Map<String, String> taskInfo = new HashMap<>();
    taskInfo.put("fileMd5", fileMd5);
    taskInfo.put("fileName", fileName);
    taskInfo.put("fileSize", String.valueOf(fileSize));
    taskInfo.put("chunkSize", String.valueOf(chunkSize));
    taskInfo.put("totalChunks", String.valueOf(totalChunks));
    taskInfo.put("uploadedChunks", "");
    stringRedisTemplate.opsForHash().putAll(UPLOAD_TASK_PREFIX + taskId, taskInfo);
    stringRedisTemplate.expire(UPLOAD_TASK_PREFIX + taskId, 24, TimeUnit.HOURS);
    
    return Result.success(taskId);
}

这里有个容易被忽略的设计点：秒传。在创建任务的时候就检查MD5，如果系统的正式存储区已经存在相同MD5的文件，说明之前有人传过完全相同的文件，直接复用就行。汽车行业的图纸文件在项目间复用率其实挺高的，同一个标准件数模被不同项目反复上传是常态，秒传能省不少存储和带宽。

MD5计算要放在前端Worker里做，文件越大计算越慢，但相比重复传一个GB级文件，这点计算成本完全值得。

3.2 分片上传接口：流式落盘

分片上传是核心接口，直接决定性能上限。

java复制@PostMapping("/upload/chunk")
public Result<String> uploadChunk(@RequestParam("file") MultipartFile file,
                                  @RequestParam("taskId") String taskId,
                                  @RequestParam("chunkIndex") int chunkIndex) {
    String taskKey = UPLOAD_TASK_PREFIX + taskId;
    if (!stringRedisTemplate.hasKey(taskKey)) {
        return Result.error("上传任务不存在或已过期");
    }
    
    // 反幂等：如果这个分片已经传过，直接返回成功
    String uploadedChunks = (String) stringRedisTemplate.opsForHash().get(taskKey, "uploadedChunks");
    if (uploadedChunks != null && uploadedChunks.contains("," + chunkIndex + ",")) {
        return Result.success("分片已存在，跳过重复上传");
    }
    
    // 保存分片到临时目录
    String chunkDir = UPLOAD_TEMP_DIR + File.separator + taskId;
    File dir = new File(chunkDir);
    if (!dir.exists()) {
        dir.mkdirs();
    }
    File chunkFile = new File(chunkDir, chunkIndex + ".part");
    try (InputStream in = file.getInputStream()) {
        Files.copy(in, chunkFile.toPath(), StandardCopyOption.REPLACE_EXISTING);
    } catch (IOException e) {
        log.error("保存分片失败, taskId={}, chunkIndex={}", taskId, chunkIndex, e);
        return Result.error("分片保存失败");
    }
    
    // 更新Redis已上传列表
    String newUploaded = uploadedChunks == null ? "," + chunkIndex + "," 
                                                : uploadedChunks + chunkIndex + ",";
    stringRedisTemplate.opsForHash().put(taskKey, "uploadedChunks", newUploaded);
    
    return Result.success("分片上传成功");
}

这段代码看起来简单，里面藏了好几个关键细节。

第一，千万别用 file.getBytes() 再写文件，这个操作会把整个分片读入内存。分片虽然不大，但并发上来几十个请求同时读，内存照样撑不住。用 file.getInputStream() 配合 Files.copy 流式写盘才是正解。

第二，分片上传要支持重复提交。网络超时后前端会重试，同一个分片可能被传两次。我的做法是在Redis里记录已上传分片的编号，每次上传前先查一遍，如果传过就直接返回成功。这个幂等处理是做断点续传的基础。

第三，分片文件按taskId在临时目录里隔离存放，文件名就是分片序号加.part后缀。这样做合并的时候直接按文件名排序就能还原顺序，不用额外维护分片顺序表。

第四，Redis的uploadedChunks字段我用逗号分隔的编号串来存，虽然不如Set结构优雅，但读写都方便，而且在分片数量不多（几百片以内）的情况下，字符串拼接完全够用。分片文件如果在几百个以上，建议升级成Redis Set结构。

3.3 合并接文件：从临时目录到正式存储

合并接口的触发条件是所有分片都上传完毕。前端在每次分片上传成功后轮询或者直接调用合并接口，后端判断是否满足条件。

java复制@PostMapping("/upload/merge")
public Result<String> mergeChunks(@RequestParam("taskId") String taskId) {
    String taskKey = UPLOAD_TASK_PREFIX + taskId;
    if (!stringRedisTemplate.hasKey(taskKey)) {
        return Result.error("上传任务不存在或已过期");
    }
    
    Map<Object, Object> taskInfo = stringRedisTemplate.opsForHash().entries(taskKey);
    int totalChunks = Integer.parseInt((String) taskInfo.get("totalChunks"));
    String uploadedChunks = (String) taskInfo.get("uploadedChunks");
    if (uploadedChunks == null) {
        return Result.error("没有已上传的分片");
    }
    
    // 检查是否所有分片都已上传
    for (int i = 0; i < totalChunks; i++) {
        if (!uploadedChunks.contains("," + i + ",")) {
            return Result.error("分片" + i + "尚未上传");
        }
    }
    
    String chunkDir = UPLOAD_TEMP_DIR + File.separator + taskId;
    String fileName = (String) taskInfo.get("fileName");
    String targetDir = UPLOAD_STORE_DIR + File.separator + LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE);
    File dir = new File(targetDir);
    if (!dir.exists()) {
        dir.mkdirs();
    }
    File targetFile = new File(targetDir, System.currentTimeMillis() + "_" + fileName);
    
    // 顺序合并分片到目标文件
    try (FileOutputStream fos = new FileOutputStream(targetFile);
         FileChannel outChannel = fos.getChannel()) {
        for (int i = 0; i < totalChunks; i++) {
            File partFile = new File(chunkDir, i + ".part");
            try (FileInputStream fis = new FileInputStream(partFile);
                 FileChannel inChannel = fis.getChannel()) {
                for (long position = 0; position < inChannel.size(); position += 1024 * 1024) {
                    outChannel.position(outChannel.size());
                    inChannel.transferTo(position, Math.min(1024 * 1024, inChannel.size() - position), outChannel);
                }
            }
            partFile.delete();
        }
    } catch (IOException e) {
        log.error("合并文件失败, taskId={}", taskId, e);
        return Result.error("合并失败");
    }
    
    stringRedisTemplate.delete(taskKey);
    return Result.success(targetFile.getAbsolutePath());
}

合并操作的核心是 FileChannel.transferTo。这个方法在Linux下底层走的是sendfile系统调用，不用把文件数据拷到用户态再写出去，性能比普通的字节流复制高一截。合并1GB文件大概在几秒内就能完成，瓶颈主要在磁盘IO。

文件合并后要做几件收尾工作：校验MD5是否和前端创建任务时上报的一致，如果不一致说明某个分片上传过程中损坏了，需要让前端重传；把文件信息写入数据库文件表，生成fileId；最后把临时目录整个删掉。

合并建议放到异步线程池里做，避免大文件合并阻塞HTTP请求线程。前端在发起合并请求后，轮询一个查询接口获取合并状态，合并完成再跳转下一步。

3.4 断点续传与秒传的工程实现

断点续传的实现逻辑其实很简单：上传前先问后端，这个任务已经传了哪些分片，然后跳过这些分片，只传剩下的。

java复制@GetMapping("/upload/status")
public Result<UploadStatusVO> queryUploadStatus(@RequestParam("fileMd5") String fileMd5) {
    UploadStatusVO vo = new UploadStatusVO();
    
    // 1. 秒传判断：MD5已存在则无需上传
    FileRecord record = fileRecordMapper.selectByMd5(fileMd5);
    if (record != null) {
        vo.setUploaded(true);
        vo.setFileId(record.getFileId());
        return Result.success(vo);
    }
    
    // 2. 查询Redis中该MD5对应任务的已上传分片
    String taskKey = stringRedisTemplate.keys(UPLOAD_TASK_PREFIX + "*").stream()
            .filter(key -> fileMd5.equals(stringRedisTemplate.opsForHash().get(key, "fileMd5")))
            .findFirst().orElse(null);
    
    if (taskKey != null) {
        String uploadedChunks = (String) stringRedisTemplate.opsForHash().get(taskKey, "uploadedChunks");
        vo.setUploaded(false);
        vo.setUploadedChunks(parseChunkList(uploadedChunks));
        return Result.success(vo);
    }
    
    vo.setUploaded(false);
    vo.setUploadedChunks(Collections.emptyList());
    return Result.success(vo);
}

前端拿到已上传分片列表后，在切片循环里跳过这些分片，只上传缺失的部分。用户刷新页面、网络断开重连、甚至换了一台电脑，只要文件MD5不变，都能从这里续上。

这里有个工程经验：断点续传的查询接口最好用文件MD5作为查询条件，而不是taskId。因为taskId是Redis里的临时值，可能过期清理；而MD5是文件的固有属性，能保证用户在任何时间点重新上传时都能找到历史进度。

秒传和断点续传是两个容易混淆的概念。秒传是文件在服务器上已经存在，无需传输直接复用；断点续传是文件传输了一半，从断点处继续传。两者的核心都是MD5，区别在于服务器上有没有完整文件。我在前端逻辑里把这两个判断做在同一个接口里，不仅能提升用户体验，还能显著减少服务器不必要的存储和带宽开销。

4. 性能优化与并发控制

4.1 分片并发数的选择与限制

很多开发第一次做分片上传，喜欢把所有分片一次性全部并发发出去，觉得这样最快。在车间内网带宽充足的情况下，这个方案确实能跑到很高的速度，但会带来两个副作用。

第一个副作用是服务端压力。100个分片同时到达，Tomcat的线程池会被占满，其他业务接口跟着遭殃。如果应用里没有做线程池隔离，上传接口能把整个应用的CPU和内存打满，PLM系统其他的查询功能全部卡住。

第二个副作用是网络拥塞。分片并发数太高，大量TCP连接同时传输，会在网络设备上造成拥塞，反而降低整体吞吐量。我在工厂里实测过，4G带宽的专线，并发数从10提到30，总体速度不升反降。

我的实践方案是前端做一个并发队列，控制同时传输的分片数在3到5个。用Promise.all配合一个简单的并发调度器实现，既不占用太多服务端资源，又能充分利用带宽。如果是内网千兆环境，可以适当上调到8到10个，但建议先用压测探一下服务端的极限。

4.2 服务端线程池隔离与异步化

服务端要把上传接口和其他业务接口做线程池隔离，避免上传流量冲击核心业务。Spring Boot里可以用自定义线程池配合异步注解实现，或者用内置的Tomcat线程池配置限制最大工作线程数。

分片上传接口的IO密集属性很强，大部分时间都在等磁盘写入，线程阻塞时间远大于计算时间。所以工作线程数可以设置得大一些，但不要超过CPU核心数的4倍。核心业务接口的线程池则要单独配置，保证上传高峰时PLM查询、审批这些关键流程不受影响。

文件合并操作一定要异步化。一个10GB的CAD文件，合并可能要几十秒，如果放在请求线程里同步执行，前端请求会超时。我的做法是合并接口收到请求后，把合并任务扔进一个定时线程池，立即返回“合并中”状态，由前端轮询查询进度。

4.3 大带宽场景下的传输限速

汽车行业的某些厂区内网带宽确实很高，文件秒传不是问题。但更多场景是跨厂区的专线，带宽有限，一个工程师开始传大文件，整个专线的其他应用全部卡顿。这种场景下，给上传做限速是体现工程师经验的地方。

前端限速比后端限速更合理，因为后端无法准确知道当前有多少个文件在同时传输，全局限速做起来很复杂。前端可以在分片调度器里加一个简单的令牌桶，限制每秒上传的字节数。

javascript复制class UploadLimiter {
    constructor(bytesPerSecond) {
        this.bytesPerSecond = bytesPerSecond;
        this.tokens = bytesPerSecond;
        this.lastRefillTime = Date.now();
    }
    
    async acquire(bytes) {
        while (this.tokens < bytes) {
            const now = Date.now();
            const elapsed = (now - this.lastRefillTime) / 1000;
            this.tokens = Math.min(this.bytesPerSecond, 
                                   this.tokens + elapsed * this.bytesPerSecond);
            this.lastRefillTime = now;
            if (this.tokens < bytes) {
                await new Promise(resolve => setTimeout(resolve, 100));
            }
        }
        this.tokens -= bytes;
    }
}

系统设置里提供给用户一个速度档位选项：不限速、2MB/s、5MB/s、10MB/s。工程师在跨厂区传文件的时候主动选择限速档位，既能完成工作，又不影响同事使用。这种细节在制造企业里非常受欢迎，是用户能直接感知到的“专业”。

4.4 大文件的传输恢复与容错

上传过程中会有各种意外：浏览器崩溃、电脑休眠、网络断开、服务端重启。设计良好的容错机制，是为了保证用户在任何情况下重新打开页面，都能从上次中断的位置继续上传。

服务端要把临时文件的生命周期拉长，不能因为应用重启就删除临时文件。应用启动时检查临时目录里有没有残留的分片，把分片信息重新注册到Redis，这样应用重启后用户依然可以续传。临时文件的自动清理策略要设成24小时甚至72小时，给用户留足恢复时间。

前端要保存上传状态的快照。考虑到页面刷新后内存数据全部丢失，前端可以把taskId、文件MD5、分片索引等信息写入localStorage。用户刷新页面后，从localStorage里恢复上传界面，自动查询服务端状态，继续未完成的部分。这个体验做好了，用户完全感知不到文件曾经中断过。

5. 常见问题与排查技巧实录

5.1 高频故障与排查手册

我把实际运维中碰到的问题整理成了一个速查表，遇到问题可以先对照排查。

5.2 我踩过的典型坑

第一个坑就是前面提到的MultipartFile.getBytes()。第一次重构时我图省事，分片接口直接用getBytes转byte数组再写文件，当时觉得分片就2MB，没啥压力。结果上线第二天，车间同时上传了30多个大文件，Tomcat直接outofmemoryerror: insufficient memory，整条产线的PLM系统瘫痪了半小时。这个教训我一直记到现在。

第二个坑是Nginx的代理缓存。生产环境前端请求先打到Nginx再转发到Tomcat。我用默认配置跑测试，发现超过100MB的文件上传总是失败，后来查Nginx日志才发现是proxy_request_buffering默认开启，Nginx先把整个请求体缓存到磁盘再转发给后端，分片上传反而被它搞成大请求了。关闭Nginx的请求缓冲后问题解决。

第三个坑是分片序号越界。前端用File.slice切分文件，单片大小和总数算得不对，导致最后一个分片大小异常，合并的时候文件尾部多了几个字节或者直接损坏。后来我统一用文件总大小除以分片大小向上取整得到分片数，最后一个分片的实际大小单独计算，才彻底解决了这个问题。

5.3 前端大文件上传的兼容性经验

虽然现在主流浏览器都支持File.slice和Web Worker，但制造企业里浏览器环境非常复杂。我见过有部门还在用Chrome 60左右的版本，也见过车间触屏机用修改版内核，兼容性测试不能只测最新版Chrome。

生产环境里建议做能力检测，前端代码里先判断window.Worker和File.prototype.slice是否存在，不支持的老浏览器直接提示升级浏览器，不要用降级方案。因为针对老浏览器的兼容代码会拖累整个上传模块的可维护性，投入产出比太低。

另外要特别关注大文件的稳定性。PDF等几MB的小文件，浏览器处理毫无压力；GB级文件读取时，内存占用和GC都会变频繁。Worker里计算完MD5之后要及时释放ArrayBuffer引用，避免Worker的内存占用持续增长。我见过一个线上问题，Worker算完3GB文件MD5后不释放内存，连续传5个文件后浏览器直接崩溃。

6. 面试官视角：JAVA大文件上传怎么答才加分

6.1 框架性的回答路径

如果面试官问“JAVA怎么实现大文件上传”，很多人的回答是：前端分片、后端合并、用Redis存状态。这个回答只能算入门，因为它只说了是什么，没有说为什么。

加分的回答要体现工程判断力。先分析业务场景：大文件上传的痛点是什么？是内存、超时、断点续传、还是完整性校验？不同的场景下方案选型的侧重点完全不同。比如内网千兆环境下，重点在并发优化；跨厂区专线环境下，重点在断点续传和限速。

然后是技术细节。聊到MultipartFile时，主动指出getBytes()的内存陷阱，强调流式写入；聊到合并时，提到FileChannel.transferTo比普通IO流更高效；聊到断点续传时，说明为什么用Redis存上传状态而不是数据库。这些细节才是面试官判断你有没有真正做过项目的依据。

最后要聊到失败处理。上传接口的幂等性、分片校验、MD5完整性验证、临时文件清理机制，这些才是生产环境和demo代码的分水岭。

6.2 常见追问与应对

面试官喜欢围绕大文件上传往下追问，我列出几个高频追问和我的应对思路。

“断点续传的难点是什么？”——难点不在技术实现，而在状态一致性和幂等性。前端要能准确知道哪些分片已经传完，后端要能处理同一个分片重复上传的情况。我用Redis存分片列表，配合分片接口的幂等判断解决。

“如果分片上传过程中服务端宕机怎么办？”——分片文件虽然在磁盘上，但Redis状态可能丢失。我的方案是应用启动时扫描临时目录，把分片信息重新注册到Redis。如果某个分片没有完整写入，下次合并时MD5校验会失败，前端重传对应分片。

“1000个分片同时传有什么问题？”——Tomcat线程池会被打满，其他业务接口无法响应。需要做线程池隔离和前端并发控制。还要考虑分片数量太多时，合并阶段的文件打开和关闭开销会很大，建议单片大小不要设太小。

“用户传到一半取消，下次还能续传吗？”——这取决于临时文件和Redis状态是否还在。清理策略可以设24小时，用户24小时内再次上传相同文件，直接续传。

这些都是面试中常见的深挖点，思路清晰、主动带出工程经验，比背八股文有用得多。

6.3 从面试题到生产能力的迁移

我见过不少候选人能把大文件上传的八股讲得头头是道，但问到底层原理就露馅。比如问为什么transferTo比普通IO快，很多人的回答是“它更快”，很少有人能说出Linux下sendfile系统调用避免了用户态和内核态之间的数据拷贝。

原因很简单：把这个问题的答案搞清楚，本质上是理解“零拷贝”这个操作系统概念。理解了这个，你就明白了为什么Java NIO的FileChannel在文件复制场景下性能远超BufferedOutputStream。这个知识迁移能力，比背一百道面试题都值钱。

大文件上传这个题目本身不复杂，但它像一张网，连着HTTP协议、浏览器API、线程池、IO模型、Redis、分布式存储。能把这张网讲清楚，说明你的JAVA基础是扎实的，而不只是会用Spring Boot。

我个人在实际项目里的体会是：大文件上传没有银弹，技术选型必须跟着业务场景走。汽车制造行业的内网条件、文件规模、用户习惯和互联网公司截然不同，一味追求并发速度或者炫技框架，最后都会被现实打脸。把这套分片上传的方案做扎实，在任何一个制造型企业里都能吃很多年。最后再分享一个小技巧：正式上线前，拿一个真实的大尺寸CAD文件，在弱网、断网、多用户并发的情况下反复测，把所有边缘场景都踩一遍，远比写一百行代码更能提升系统的健壮性。