Spring Boot 2.7.2 中 multipart 临时文件（如 /tmp/tomcat.*）未被自动删除，主要因旧版本缺乏可靠的清理机制；升级至 Spring Boot 3.x（基于 Spring Framework 6.x）可启用内置自动清理能力，并配合 spring.servlet.multipart.max-in-memory-size 等配置优化内存与磁盘使用。
spring boot 2.7.2 中 multipart 临时文件（如 `/tmp/tomcat.*`）未被自动删除，主要因旧版本缺乏可靠的清理机制；升级至 spring boot 3.x（基于 spring framework 6.x）可启用内置自动清理能力，并配合 `spring.servlet.multipart.max-in-memory-size` 等配置优化内存与磁盘使用。
在 Spring Boot 应用中处理文件上传时，若请求体超过内存阈值（默认 256KB），Servlet 容器（如 Tomcat）会将超出部分写入临时磁盘文件（通常位于 /tmp 下形如 tomcat.*.tmp 的文件）。这些临时文件本应由容器在请求结束后自动清理，但在 Spring Boot 2.7.x 及更早版本中，由于 Spring Framework 5.x 对 DefaultPartHttpMessageReader 的资源生命周期管理不完善，常导致文件残留，引发磁盘空间耗尽风险。
✅ 根本解决方案：升级至 Spring Boot 3.x
Spring Boot 3.x 基于 Spring Framework 6.0+，已集成更健壮的 multipart 清理机制：
- DefaultPartHttpMessageReader 在读取完成后主动调用 Part.delete()；
- Tomcat 10.1+ 与 Undertow 2.3+ 等容器也同步增强了临时文件生命周期管理；
- 框架层面确保 HttpServletRequest.getParts() 返回的 Part 对象在 StandardMultipartHttpServletRequest 销毁时触发清理。
? 关键配置建议（application.yml）：
spring:
servlet:
multipart:
max-file-size: 10MB
max-request-size: 10MB
# 提高内存阈值，减少磁盘临时文件生成频率
max-in-memory-size: 5MB # 默认为 256KB，合理增大可降低/tmp写入次数
⚠️ 注意事项：
- 升级前务必确认 JDK 版本 ≥ 17（Spring Boot 3.x 强制要求）；
- 若暂无法升级，可临时通过 @Bean MultipartConfigElement 手动指定 location 并定期清理（不推荐生产环境长期使用）；
- 避免在代码中显式调用 part.write() 或 part.getInputStream() 后忽略 part.delete() —— Spring Boot 3.x 已自动保障，但自定义逻辑仍需注意资源释放。
总结：Spring Boot 2.7.2 存在 multipart 临时文件泄漏隐患，这不是配置缺陷，而是框架底层生命周期管理能力的局限。唯一稳健、符合官方支持路径的方案是升级至 Spring Boot 3.x，并结合 max-in-memory-size 等参数优化上传行为，从而实现临时文件的自动、可靠清理。
