spring boot分片上传需三个核心接口:get /api/upload/check检查已传分片、post /api/upload/chunk上传单个分片、post /api/upload/merge触发合并;配合流式写入、md5命名隔离、nginx及spring boot参数调优,实现断点续传与秒传。

Spring Boot 中传大文件分片,核心是把一个大文件切成小块(chunk),前端按序或并发上传,后端逐个接收、暂存,最后合并。不靠单次大请求,而是用三个轻量接口协同完成:检查状态、上传分片、合并文件。
分片上传需要哪几个关键接口
服务端只需定义三个清晰接口,无需复杂框架:
-
检查已上传分片:GET
/api/upload/check?fileMd5=xxx&fileName=xxx,返回已成功上传的分片序号列表(如[0, 1, 3]),前端据此跳过重传,实现断点续传 -
上传单个分片:POST
/api/upload/chunk,携带file(MultipartFile)、fileMd5、chunkIndex(从 0 或 1 开始需前后端约定)、totalChunks,后端按规则落盘到临时目录(如/tmp/uploads/{md5}/{index}) -
触发合并:POST
/api/upload/merge?fileMd5=xxx&fileName=xxx&totalChunks=12,服务端校验所有分片是否齐全,按序读取、拼接、生成最终文件,并清理临时分片
后端怎么安全接收和存储分片
每个分片本质仍是 MultipartFile,但处理逻辑与普通上传不同:
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式,或要求按照代码注释规范处理 Java 文件时,使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则,并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括:补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 禁用默认的内存缓冲,改用流式写入:调用
file.getInputStream()直接写入磁盘,避免 OOM;不要调用file.getBytes()或file.transferTo()(后者在部分容器中可能出错) - 临时文件命名必须含唯一标识:推荐用
fileMd5 + chunkIndex命名,路径隔离到/tmp/chunks/{md5}/,防止不同用户/文件冲突 - 每次上传分片前做基础校验:检查
chunkIndex是否越界、file是否为空、单片大小是否合理(如 ≤5MB),非法请求直接拒绝 - 可选加一层秒传:在
/check接口里先查数据库或文件系统,若fileMd5对应完整文件已存在,直接返回成功路径,跳过后续所有步骤
配置和边界要特别注意什么
Spring Boot 默认限制 multipart 请求大小,大分片必须显式放宽:
- 在
application.yml中设置:
spring:
servlet:
multipart:
max-file-size: 5MB
max-request-size: 50MB
这里max-file-size应 ≥ 单个分片大小,max-request-size应 ≥ 最大可能的单次请求(通常就是单个分片) - Controller 方法必须明确声明 consumes:
@PostMapping(value = "/chunk", consumes = MediaType.MULTIPART_FORM_DATA_VALUE),否则 Spring 可能无法正确绑定MultipartFile - 若部署在 Nginx 后,还需同步调大
client_max_body_size和proxy_buffering off,避免网关层拦截
前端配合的关键点
后端再稳,前端没对齐也白搭:
- 分片大小建议固定(如 4MB 或 5MB),前端用
File.slice()切分,确保每片字节精准,避免合并时错位 - 所有请求都带上
fileMd5和chunkIndex,最好再带fileName和totalChunks,方便后端校验上下文 - 上传失败后,前端主动调用
/check获取最新进度,再只重传缺失或失败的分片,而非盲目重试全部 - 合并请求成功后,务必检查响应体中的实际文件路径或 ID,用于后续业务引用,不要假设路径可推算










