Spring中如何将请求体部分字段映射为InputStream实现大文件流式上传

你当前的实现方式完全无法满足大文件流式处理的需求，核心原因有三个：

• 你用@RequestBody+自动JSON反序列化的方式接收参数时，Spring默认集成的Jackson会把整个请求体完整加载进内存完成解析，才会进入Controller逻辑，只要文件体积够大必然触发OOM
• 你定义的MyClass里的InputStream fileContent字段不会被Jackson按流处理，Jackson会先把整个base64字符串读入内存，解码后才会转换成输入流，本质还是全量加载
• base64编码本身存在33%的体积膨胀，用它传超大文件本身就会额外浪费带宽和内存

直接放弃application/json+base64的传输格式，改用HTTP标准的multipart/form-data格式传输，Spring对这种格式有原生的流式处理支持，不需要自己写解析逻辑，稳定性和性能都有保障。

代码实现 #

1. 定义纯元数据的DTO，去掉文件字段

public class FileMetaDTO {
  private String name;
  private String version;
  private String author;
  // 构造方法、getter、setter自行补充
}

2. 改上传接口，用@RequestPart分别接收元数据和文件

@PostMapping(path = "/upload", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public ResponseEntity<String> upload(
        @RequestPart("meta") FileMetaDTO meta,
        @RequestPart("file") MultipartFile file
) throws IOException {
    // 第一步：元数据直接存数据库
    fileMetaRepository.save(meta);
    // 第二步：直接获取文件输入流，全程不加载全量文件到内存
    try (InputStream fileIs = file.getInputStream();
         OutputStream targetOs = buildTargetStorageOutputStream(meta) // 替换为你的目标存储输出流，比如OSS、分布式存储、本地文件输出流
    ) {
        // 8KB缓冲区流式拷贝，内存占用恒定
        StreamUtils.copy(fileIs, targetOs);
    }
    return ResponseEntity.ok("upload success");
}

方案说明 #

• Spring默认的Multipart解析器只会把小于16KB（默认阈值）的文件存在内存，超过阈值的文件会顺序写入本地临时目录，你调用getInputStream()时直接读取临时文件流，传输完成后Spring会自动清理临时文件，哪怕传几十G的文件，内存占用也只有几十KB的缓冲区大小，不会OOM
• 请求不需要做base64编码，文件以原始二进制格式传输，比base64方案省33%左右的传输带宽
• 元数据part依然支持JSON格式的自动序列化、参数校验，和你之前用@RequestBody的体验一致
• 如果不想让文件临时落本地，可以在配置里把spring.servlet.multipart.file-size-threshold设为0，调整解析器为纯流模式即可，默认的临时文件落盘方案性能损耗极低，绝大多数场景不需要调整

如果你因为客户端限制必须保留原有application/json的请求格式，也可以实现，但维护成本和出错概率极高。
核心思路是放弃Spring的自动JSON反序列化，直接拿请求的原始输入流，用Jackson的流式解析器逐Token解析JSON，遇到base64文件字段时直接拿解码流边读边写，不把完整内容加载进内存。

核心代码示例 #

@PostMapping(path = "/upload", consumes = MediaType.APPLICATION_JSON_VALUE)
public ResponseEntity<String> upload(HttpServletRequest request) throws IOException {
    FileMetaDTO meta = new FileMetaDTO();
    JsonFactory jsonFactory = JsonFactory.builder().build();
    try (JsonParser parser = jsonFactory.createParser(request.getInputStream())) {
        // 定位到JSON根对象起始位置
        parser.nextToken();
        // 遍历所有JSON字段
        while (parser.nextToken() != JsonToken.END_OBJECT) {
            String field = parser.getCurrentName();
            parser.nextToken();
            switch (field) {
                case "name":
                    meta.setName(parser.getText());
                    break;
                case "version":
                    meta.setVersion(parser.getText());
                    break;
                case "author":
                    meta.setAuthor(parser.getText());
                    break;
                case "fileContent":
                    // 关键：不要调用getText()读取完整base64字符串，直接获取解码后的二进制流
                    try (InputStream base64Is = parser.getBinaryValueStream();
                         OutputStream targetOs = buildTargetStorageOutputStream(meta)
                    ) {
                        StreamUtils.copy(base64Is, targetOs);
                    }
                    break;
                default:
                    // 跳过不认识的字段
                    parser.skipChildren();
            }
        }
    }
    // 元数据存库
    fileMetaRepository.save(meta);
    return ResponseEntity.ok("upload success");
}

该方案的限制 #

• 必须保证fileContent是JSON结构的最后一个字段，否则解析完文件流后无法继续读取后续字段，会触发解析错误
• 没有全局自动JSON异常处理、参数校验，所有边界情况需要自己处理
• base64的体积膨胀问题依然存在，传输效率低
• JSON结构调整时必须同步修改解析逻辑，维护成本高

内容的提问来源于stack exchange，提问作者emsiiggy