Spring Boot 1.5.13多部分请求解析异常问题求助

针对你遇到的两个疑问，我结合Spring Boot 1.5.x的运行机制逐一解释：

疑问1：未使用文件上传，调用RestTemplate Post时为何触发multipart解析异常？ #

这个异常其实不是来自你作为客户端调用RestTemplate的行为，而是你的应用作为服务端接收到了带有multipart/form-data类型的请求——哪怕你没写任何文件上传接口，Spring Boot 1.5.x默认会自动配置StandardServletMultipartResolver，这个组件会自动尝试解析所有Content-Type为multipart/form-data的请求。

为什么会收到这类请求？可能的场景包括：

• 测试时不小心发送了multipart类型的请求到你的应用接口
• 第三方服务的回调请求使用了这个Content-Type
• 甚至可能是你的RestTemplate调用逻辑有误，不小心把请求打到了自己的应用接口上

而此时Linux系统的/tmp目录（Tomcat默认临时上传目录）已经被定期清理机制删掉了，Tomcat找不到临时目录来解析请求，就抛出了这个异常。

疑问2：重启后未立即恢复，一天后才正常，是否存在缓存？ #

重启应用时Tomcat本应重新生成临时上传目录，但你遇到的情况大概率和这几个原因有关：

1. Bean未正确刷新：如果你的应用中有自定义的Multipart相关配置，或者某些依赖缓存了旧的临时目录路径，重启后这些缓存没有被清空，导致组件依然尝试访问已被删除的旧目录。
2. 多实例/负载均衡问题：如果你的应用部署了多个实例，你只重启了其中一个，请求依然可能打到未重启的实例上，而那个实例的临时目录还是失效状态。
3. 系统文件缓存：极少数情况下，Linux系统的文件系统缓存可能残留了旧目录的信息，导致应用误以为目录还存在，直到缓存过期（这可能就是一天后恢复的原因）。

解决建议 #

为了彻底避免这个问题，你可以选以下两种方案：

• 自定义临时目录：在application.properties里配置Tomcat的基础目录，避免使用系统的/tmp：

  server.tomcat.basedir=./tomcat-temp
  

  这样Tomcat会把临时上传目录放在你指定的路径下，不会被系统自动清理。
• 禁用Multipart自动配置：如果你完全不需要处理任何multipart请求，直接在启动类上排除自动配置：

  @SpringBootApplication(exclude = MultipartAutoConfiguration.class)
  

  这样Spring就不会初始化MultipartResolver，自然不会触发这类解析异常。

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