Spring Boot RestController 如何流式处理multipart/form-data请求避免内存过高？

DevOps 小满

2026-11-6

核心结论

完全可以实现无内存/临时磁盘缓存的端到端流式处理。你之前遇到的缓存问题本质是在触发真正的流读取之前，就提前触发了框架层面的multipart全量解析，和是否使用commons-fileupload组件没有直接关系——甚至纯转发场景根本不需要解析multipart结构。

之前尝试未达预期的根因

Spring Boot默认开启spring.servlet.multipart.enabled=true，请求在到达业务代码前，就已经被DispatcherServlet里的解析器全量读取，要么加载到内存要么写入临时磁盘，等你拿到请求对象时，原始TCP连接上的字节流早被替换成了缓存内容，换什么解析组件都没用
就算手动关闭了Spring的解析，很多人实现时非要在Service A端把multipart拆成表单项和文件，这个拆分过程本身就需要缓存内容匹配边界字符串，天然引入缓存开销，对于纯转发场景完全是多余操作
commons-fileupload默认的内存阈值、临时文件缓存策略没有调整，只要触发解析就会落盘，根本达不到预期的流式效果

零缓存流式转发的实现步骤

彻底关闭框架自动multipart解析
在配置文件中设置：
spring.servlet.multipart.enabled=false
该配置会完全关闭Spring及底层Tomcat的multipart自动解析逻辑，请求到达业务代码前不会做任何请求体的读取、缓存操作
直接获取原始请求输入流
Controller方法中不要声明MultipartFile、MultipartHttpServletRequest这类会触发解析的参数，直接注入原始HttpServletRequest对象，调用request.getInputStream()拿到从TCP连接直接读取的原始字节流——这个流没有任何预缓存，读取多少就从对端拉多少

透传原始请求给下游Service B
千万不要为了转发刻意在A端拆分multipart结构，直接把原始输入流作为请求体，配合Spring 6的RestClient（或WebClient）流式请求能力发送给下游：

@PostMapping(value = "/forward", consumes = MediaType.MULTIPART_FORM_DATA_VALUE)
public void forwardRawRequest(HttpServletRequest request, HttpServletResponse response) throws IOException {
    InputStream rawRequestStream = request.getInputStream();
    restClient.post()
        .uri("http://service-b/target-endpoint")
        .headers(headerBuilder -> {
            // 透传原请求的核心请求头，跳过逐跳传输头（Connection、Keep-Alive、TE等）
            Enumeration<String> headerNames = request.getHeaderNames();
            while (headerNames.hasMoreElements()) {
                String headerName = headerNames.nextElement();
                String lowerName = headerName.toLowerCase();
                // 跳过不应该透传的逐跳头
                if (Set.of("connection", "keep-alive", "te", "trailer", "transfer-encoding", "upgrade").contains(lowerName)) {
                    continue;
                }
                headerBuilder.set(headerName, request.getHeader(headerName));
            }
        })
        .body(rawRequestStream) // 直接绑定原始流，客户端会边读边通过chunked编码发送，无全量缓存
        .retrieve()
        // 下游响应同样做流式透传，不缓存响应体
        .toEntity(response.getOutputStream());
}

排除会隐式缓存请求体的链路组件
检查所有Filter、拦截器逻辑，避免出现全局读取请求体打日志、全量校验请求签名这类操作；如果必须读请求头做校验，严禁读取request.getInputStream()的全部内容。

关键注意事项

不要手动重新构造multipart请求：为了转发而把文件重新打包为multipart格式的操作，必然会触发文件内容的全量加载，是性能最差的实现路径
对于大小无限制的文件，上述实现全程仅在内存中保留几十KB的读写缓冲区，不会因为文件大就占用更多内存
如果确实需要在A端解析部分multipart字段（而非纯转发），可以直接在原始输入流基础上，通过边界字符串逐字节扫描拆分表单项，全程保持边读边转发，不需要引入commons-fileupload的缓存逻辑

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