Spring Boot 2.7.2 中 multipart 临时文件未自动删除，需升级至 Spring Boot 3.x（基于 Spring Framework 6.x），并合理配置 spring.servlet.multipart.max-in-memory-size 等参数，利用内置的自动清理机制释放 /tmp 目录空间。
spring boot 2.7.2 中 multipart 临时文件未自动删除，需升级至 spring boot 3.x（基于 spring framework 6.x），并合理配置 `spring.servlet.multipart.max-in-memory-size` 等参数，利用内置的自动清理机制释放 `/tmp` 目录空间。
在 Spring Boot 应用中处理文件上传时，若请求体超过内存阈值（默认 256KB），Servlet 容器会将超出部分写入磁盘临时目录（如 /tmp/tomcat.*），生成 tmp 文件。然而，在 Spring Boot 2.x（包括 2.7.2）中，这些临时文件不会被自动清理，长期运行可能导致磁盘空间耗尽。
根本原因在于：Spring Framework 5.x（对应 Spring Boot 2.x）依赖 Servlet 容器（如 Tomcat）自身的清理逻辑，而 Tomcat 仅在 Context 重启或 JVM 退出时才尝试删除临时文件，缺乏运行时主动回收机制。
✅ 推荐解决方案：升级至 Spring Boot 3.2+（即 Spring Framework 6.1+）
Spring Framework 6.1 起引入了 DefaultPartHttpMessageReader 的增强清理能力，配合 StandardMultipartResolver 可在请求结束后自动删除已解析的临时文件（参见 Spring Framework #27633）。
关键配置示例（application.yml）：
spring:
servlet:
multipart:
max-file-size: 10MB
max-request-size: 10MB
# 提高内存阈值，减少磁盘落盘频率（默认 256KB）
max-in-memory-size: 5MB
# 启用更严格的资源管理（Spring Boot 3.2+ 默认启用）
# cleanup-on-resolve: true # Spring Boot 3.3+ 显式支持该属性⚠️ 注意事项：
- 升级前务必确认 JDK 版本 ≥ 17（Spring Boot 3.x 强制要求）；
- 若无法立即升级，可临时通过自定义 MultipartConfigElement 或 @Bean MultipartResolver 实现手动清理（不推荐长期使用）；
- 避免依赖 System.getProperty("java.io.tmpdir") 的硬编码路径清理，应交由 Spring 框架统一管理；
- 生产环境建议配合监控（如 Prometheus + Node Exporter）告警 /tmp 使用率。
总结：临时文件堆积不是配置疏漏，而是旧版本框架能力限制。升级至 Spring Boot 3.x 是最安全、标准且可持续的解决路径——既获得自动清理保障，又同步享有性能优化、HTTP/2 原生支持及更强的安全基线。
