Java 大文件上传处理（从简单到生产级完整方案）
在实际项目中，上传几百MB甚至几个GB的文件非常常见。如果直接用普通的MultipartFile一次性接收，会导致以下问题：
- 内存溢出（OutOfMemoryError）
- 请求超时（timeout）
- 上传中断后需要重头开始
- 服务器压力巨大
核心解决方案：分片上传（Chunk Upload） + 断点续传 + 秒传
下面从零基础到生产级，一步步带你搞懂 Java 处理大文件上传的最佳实践（2024-2025 主流方案）。
一、不同场景推荐方案对比
| 文件大小 | 并发量 | 推荐方案 | 核心技术 | 复杂度 | 内存占用 |
|---|---|---|---|---|---|
| < 100MB | 低 | 普通 MultipartFile | Spring Boot 默认 | ★☆☆☆☆ | 中等 |
| 100MB ~ 2GB | 中 | 流式接收 + 临时文件 | InputStream + FileOutputStream | ★★☆☆☆ | 低 |
| > 2GB 或重要业务 | 高 | 分片上传 + 断点续传 + 秒传 | 前端切片 + 后端合并 + Redis/MySQL记录 | ★★★★☆ | 极低 |
| 云存储场景 | 高 | 直接走云厂商分片接口 | OSS/S3/COS 多部分上传 | ★★☆☆☆ | 几乎无 |
绝大多数中大型项目现在都推荐第3种：分片 + 断点续传 + 秒传
二、主流实现方式（推荐生产级方案）
整体流程：
- 前端：把大文件切成固定大小的分片（通常 5MB~20MB 一片）
- 前端：计算整个文件的唯一标识（MD5 / SHA256）
- 前端：先发一个“校验”请求 → 服务器告诉哪些分片已存在（实现秒传 & 续传）
- 前端：并发或串行上传缺失的分片（带分片序号、文件hash）
- 后端：接收分片 → 存临时目录或直接写到最终文件对应位置
- 前端：所有分片上传完后 → 发“合并”请求
- 后端：合并分片 → 校验完整性 → 转移到正式目录
三、后端核心代码（Spring Boot 实现）
1. 配置文件（非常重要！防止内存爆炸）
spring:servlet:multipart:enabled:truemax-file-size:10GB# 单文件最大max-request-size:10GB# 单次请求最大file-size-threshold:0# 立即写磁盘，不占内存2. Controller 接口（推荐写法）
@RestController@RequestMapping("/file")publicclassBigFileController{// 临时目录（建议配置到外部磁盘）privatestaticfinalStringTEMP_DIR="/data/upload_temp/";privatestaticfinalStringFINAL_DIR="/data/upload_final/";// 1. 校验文件是否已存在（秒传） + 返回已上传分片@GetMapping("/check")publicResultcheckFile(@RequestParamStringfileMd5,@RequestParamLongfileSize){// 查询 Redis 或 DB 是否有该 md5 的完整文件if(fileExistsInDb(fileMd5)){returnResult.ok("文件已存在，可秒传",getFileUrl(fileMd5));}// 返回已上传的分片索引列表（比如 [0,1,3,5]）List<Integer>uploadedChunks=getUploadedChunks(fileMd5);returnResult.ok(uploadedChunks);}// 2. 上传分片@PostMapping("/upload/chunk")publicResultuploadChunk(@RequestParam("file")MultipartFilechunk,@RequestParamStringfileMd5,@RequestParamIntegerchunkIndex,// 分片序号 0,1,2...@RequestParamIntegertotalChunks){try{StringchunkFileName=fileMd5+"_"+chunkIndex;FilechunkFile=newFile(TEMP_DIR+fileMd5+"/"+chunkFileName);// 已存在则跳过（幂等）if(chunkFile.exists()){returnResult.ok("分片已存在");}// 流式写入磁盘（内存占用极低）chunk.transferTo(chunkFile);// 记录分片信息到 Redis（推荐）或 DBsaveChunkInfo(fileMd5,chunkIndex);// 如果所有分片都齐了，自动触发合并（可选）if(isAllChunksUploaded(fileMd5,totalChunks)){mergeChunks(fileMd5,totalChunks);}returnResult.ok();}catch(Exceptione){returnResult.error("上传失败："+e.getMessage());}}// 3. 手动触发合并（前端所有分片上传完后调用）@PostMapping("/merge")publicResultmerge(@RequestParamStringfileMd5,@RequestParamIntegertotalChunks){if(!isAllChunksUploaded(fileMd5,totalChunks)){returnResult.error("分片未全部上传完成");}mergeChunks(fileMd5,totalChunks);returnResult.ok("合并成功",getFileUrl(fileMd5));}privatevoidmergeChunks(StringfileMd5,inttotalChunks)throwsIOException{FilefinalFile=newFile(FINAL_DIR+fileMd5+".bin");// 真实项目用原文件名try(FileOutputStreamfos=newFileOutputStream(finalFile,true)){for(inti=0;i<totalChunks;i++){Filechunk=newFile(TEMP_DIR+fileMd5+"/"+fileMd5+"_"+i);if(!chunk.exists())thrownewIOException("分片缺失："+i);Files.copy(chunk.toPath(),fos);chunk.delete();// 删除分片，节省空间}}// 存库、记录MD5、原文件名、大小、路径等saveToDb(fileMd5,finalFile);// 可选：删除临时文件夹}}四、关键优化点（生产必须做）
- 分片大小：5MB~20MB 最合适（太小请求多，太大重传代价高）
- 幂等性：同一个分片重复上传不报错
- 断点续传：前端记录已上传分片，后端返回已上传列表
- 秒传：文件MD5已存在直接返回成功
- 并发上传：前端用 Promise.all 或 Web Worker 并发 3~6 个分片
- 存储已上传分片：推荐用 Redis Set（
file:{md5}:chunks），过期时间设长一点 - 文件名处理：前端传原始文件名，后端用 md5 + 后缀存储，数据库保存映射
- 进度条：前端计算已上传分片数 / 总分片数
- 失败重试：前端对失败分片自动重试 3 次
- Nginx 代理：上传走单独域名，配置 client_max_body_size 10G;
五、云厂商推荐（最省事）
- 阿里云 OSS →分片上传（Multipart Upload）
- 腾讯云 COS →分块上传
- 七牛云 KODO →分片上传
- AWS S3 →Multipart Upload
后端基本只负责签名，前端直传，性能和稳定性最好。
六、总结一句话
普通小文件→ 用MultipartFile就行
真正的大文件（>500MB）→ 必须做分片 + 断点续传 + 秒传，核心是“前端切片 + 后端记录分片状态 + 最后合并”
追求极致省心→ 直接用云存储的分片上传接口
你现在是想自己实现一套分片上传，还是接云厂商的？或者有具体问题（比如 Redis 怎么存、合并时怎么保证顺序等），可以继续说～
