public class FileController {
FileService fileService;
@PostMapping("/upload")
public ResponseEntity upload(@RequestParam("file") MultipartFile file) {
if (fileService.trySave(file)) {
return ResponseEntity.ok("File uploaded successfully");
}
return ResponseEntity.internalServerError().body("Failed to upload the file");
}
}
（ Service 的代码就不放了，因为对于问题来说不重要）
然后测试了一下接口，我把 url 打错了，然后上传了一个比较大的文件，结果请求了很久才返回 404 的 response 。
然后我又试了以下，并且在期间打开任务管理器，发现 jdk binary 的磁盘 IO 高起来了。。等了半天，大约是文件传完了（或者说 HTTP 请求体传完了）才返回 resp 。
然后我问 GPT 为什么会这样，它说因为我用 HTTP 请求传文件，服务端就是要接受了整个请求体（包含大文件）之后，才会处理 url 匹配之类的逻辑。我越想越离谱，这不是意味着我可以往接受大文件上传的域名一直发文件吗？然后每个被我请求的服务器都要进行磁盘 IO ，就因为这个 HTTP 协议的特性？
然后我问了 GPT 解决方法，它给出
用客户端做可达性分析
似乎脱离了讨论的范畴，因为我直接测的接口，想知道在这个前提下的解决办法是什么
用中间件验证权限和 url
中间件也是服务器，也需要接受 HTTP 请求，那不也浪费了资源吗？
用分片上传
似乎还是无法避免浪费资源
好像这些办法都没用，因为大前提都是使用了 HTTP 请求，因此服务器必须要接受这个请求之后再处理。。因此我看不出这些方法解决这个问题的可行性。
渴望有人指点下我的迷惑。
