嗨，这个问题问到点子上了，刚好涉及到Servlet容器和Spring Boot处理multipart请求的底层逻辑，我来给你梳理清楚：

首先得明确核心：MultipartFile的输入流行为，本质上是由你用的嵌入式Servlet容器（比如默认的Tomcat、Jetty）的multipart处理策略决定的，咱们分情况说：

1. 默认配置下的行为（最常见的场景） #

以Tomcat为例，Spring Boot默认的multipart配置会把超过一定大小的文件（比如你的1GB文件）直接写入服务器的临时磁盘目录（一般是系统临时目录下的Tomcat临时文件夹），而不是存在内存里。这时候：

• 你延迟读取MultipartFile的输入流，其实读的是本地磁盘上的临时文件，完全不会导致服务器内存被未读取的上传数据填满——因为数据早就被容器落地到磁盘了，内存里只会存一些文件元数据和小缓冲区数据。
• 客户端这边：一开始会正常发送数据，当Tomcat的接收缓冲区（用来暂存待写入磁盘的小块数据）填满后，TCP的滑动窗口机制会触发背压，客户端会被阻塞，暂停发送数据，直到Tomcat把缓冲区里的数据刷到磁盘、腾出空间，或者你开始读取流，客户端才会继续发送。如果延迟时间太长，可能会触发客户端或服务器的超时配置（比如Tomcat的connectionTimeout），导致请求直接中断，抛出超时异常。

2. 自定义multipart配置后的特殊情况 #

如果你手动调整了spring.servlet.multipart.file-size-threshold参数（比如设为100MB），这个参数的意思是：当上传的文件片段大小低于阈值时，容器会暂存到内存；超过阈值则落地到磁盘。但对于1GB的大文件来说，哪怕阈值设得再高，容器也不可能把1GB的完整数据塞进内存，最终还是会把大部分数据写到临时磁盘文件里。所以哪怕延迟读取，内存也只会占用阈值以内的小部分缓存，不会出现内存溢出的风险。

3. 流式上传的特殊场景（不落地临时文件） #

如果你想实现真正的边接收边处理（比如直接把上传流写到存储服务，不经过服务器临时文件），可以用Spring的StreamingMultipartFile或者直接操作Servlet的Part对象的输入流。这时候：

• 你延迟读取输入流的话，服务器的接收缓冲区（一般只有几KB到几十KB）会先存一部分数据，等缓冲区满了，TCP背压会让客户端暂停发送，所以内存只会占用这一小块缓冲区的空间，不会爆内存。
• 同样，延迟太久还是会触发超时，导致请求中断。

最后给你划个重点 #

不管是哪种配置，延迟读取MultipartFile的输入流都不会导致服务器内存被未读取的大文件数据填满——要么数据在磁盘，要么只有小缓冲区在内存。需要注意的是超时配置，别让延迟时间超过了客户端或服务器的超时限制，不然请求会直接失败。

要是还有细节想深挖可以再问~