1. 这个报错到底在喊什么——从日志第一行读懂问题本质“StandardServletMultipartResolver : Failed to perform cleanup of multipart items”——这行日志不是警告是Spring Boot应用在文件上传流程中发出的明确求救信号。它不指向某个具体业务逻辑错误而是底层资源管理失控的典型症状Spring已成功接收并解析了用户上传的文件MultipartFile但在请求生命周期结束前无法安全释放这些临时文件所占用的磁盘空间和句柄资源。我第一次看到这个报错时正调试一个用户头像批量上传接口表面看功能完全正常——图片能存、数据库能写、前端能预览但每调用一次服务器/tmp目录就多出几个几十MB的临时文件三天后磁盘告警。后来查日志才发现这行报错每天刷屏上百次而它背后隐藏的是Java NIO通道未关闭、InputStream未消费完、Jakarta Servlet API迁移兼容性断层这三重陷阱。这个报错高频出现在Spring Boot 2.3对应Jakarta EE 9及更高版本项目中尤其当项目混用旧版javax.servlet.*和新版jakarta.servlet.*包时它会伪装成“偶发性IO异常”实则暴露的是整个文件上传链路的资源生命周期管理漏洞。核心关键词StandardServletMultipartResolver是Spring MVC默认的文件上传解析器它依赖Servlet容器Tomcat/Jetty提供的multipart支持Failed to perform cleanup of multipart items直译是“执行multipart项清理失败”但真正失败的从来不是cleanup方法本身而是它试图清理的对象——那些本该被及时关闭却滞留在内存或磁盘的InputStream和临时文件句柄。而IOUtils作为Apache Commons IO的经典工具类常被开发者用来读取MultipartFile内容却恰恰是触发此报错的最常见操作入口。你不需要精通Servlet规范细节但必须明白每一次文件上传Spring都会在/tmp下创建临时文件并持有一个指向它的InputStream这个流一旦没被彻底读完或显式关闭cleanup阶段就会因句柄被占用而失败。这个问题对新手极不友好——它不阻断业务却在后台悄悄拖垮系统稳定性。2. 深度拆解为什么cleanup会失败三层技术根源全曝光2.1 根源层Servlet API迁移引发的类加载冲突Spring Boot 2.3是分水岭。此前版本基于Java EE规范使用javax.servlet.http.Part2.3起全面拥抱Jakarta EE 9所有包名从javax.切换为jakarta.。但现实项目中大量老旧依赖如某些国产中间件SDK、自研工具包、甚至部分Spring Security旧版starter仍硬编码引用javax.servlet.*。当Tomcat 10原生支持Jakarta加载这些类时ClassLoader会尝试同时加载javax.servlet.http.Part和jakarta.servlet.http.Part两个同名类——它们字节码结构一致但JVM视其为完全不同的类型。StandardServletMultipartResolver内部通过反射调用Part.delete()方法清理临时文件若反射目标类实际加载的是javax版本而Servlet容器提供的是jakarta版本实例就会抛出NoSuchMethodException或ClassCastException最终导致cleanup静默失败。我曾在一个金融客户项目中复现此问题他们使用的某银行支付SDK强制依赖javax.servlet-api 4.0.1而Spring Boot 2.7.18自带jakarta.servlet-api 4.0.4两者在同一个ClassLoader下共存结果每次上传后临时文件堆积如山日志里却只显示“Failed to perform cleanup”连堆栈都不完整。2.2 执行层InputStream未耗尽导致文件句柄锁定这是最隐蔽也最普遍的根源。MultipartFile.getInputStream()返回的InputStream并非普通字节数组流而是直接绑定到Servlet容器创建的临时文件句柄。当你调用IOUtils.toString(input, UTF-8)读取文本文件时如果文件含BOM头或编码不匹配IOUtils可能提前抛出IOException并中断读取但底层FileInputStream句柄并未释放更常见的是开发者为获取文件大小而调用multipartFile.getSize()后误以为“已读取”实际InputStream指针仍在开头后续业务逻辑若未消费该流cleanup阶段尝试delete临时文件时就会因Windows系统文件被占用java.nio.file.FileSystemException: ...: The process cannot access the file because it is being used by another process而失败。实测数据在Windows Server 2019上一个未关闭的InputStream会让临时文件锁定长达30秒以上Linux虽无严格锁定但inode引用计数不归零会导致磁盘空间无法回收。关键在于Spring的cleanup逻辑在DispatcherServlet.doDispatch()末尾执行此时业务方法早已return你根本无法在Controller里捕获这个异常。2.3 架构层StandardServletMultipartResolver自身设计缺陷很多人以为换用CommonsMultipartResolver就能解决其实不然。StandardServletMultipartResolver是Spring官方推荐方案其cleanup机制依赖Servlet规范定义的Part.delete()——这是一个“尽力而为”的操作规范明确说明“容器不保证立即删除”。问题在于Spring在AbstractMultipartHttpServletRequest.destroy()中调用cleanupMultipart()时对每个Part执行delete()后不做任何失败校验。源码片段如下for (Part part : this.request.getParts()) { try { part.delete(); // 关键此处无异常捕获无失败重试 } catch (Exception ex) { // 完全忽略日志只打warn级别 if (logger.isWarnEnabled()) { logger.warn(Failed to perform cleanup of multipart items, ex); } } }这意味着即使delete()因权限不足、磁盘满、路径不存在等任何原因失败Spring都选择沉默仅输出那行经典报错。而CommonsMultipartResolver虽用DiskFileItemFactory管理临时文件但其cleanup同样依赖finalize()或WeakReferenceGC时机不可控反而更容易在高并发下出现临时文件残留。3. 实操验证三步定位真实故障点附可复现代码3.1 第一步确认是否Jakarta兼容性问题新建一个极简Controller绕过所有业务逻辑直击Servlet API层RestController public class DebugController { PostMapping(/debug-upload) public String debugUpload(RequestParam(file) MultipartFile file) throws Exception { // 强制触发Part.delete() HttpServletRequest request ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest(); CollectionPart parts request.getParts(); System.out.println(Parts count: parts.size()); for (Part part : parts) { System.out.println(Part name: part.getName() , submittedFileName: part.getSubmittedFileName() , class: part.getClass().getName()); // 关键打印实际类名 } return OK; } }启动应用用curl上传文件curl -X POST http://localhost:8080/debug-upload \ -F filetest.txt观察控制台输出。若看到类似class org.apache.catalina.connector.Request$PartImplTomcat 9或class org.apache.catalina.connector.Request$JakartaPartImplTomcat 10说明Servlet容器正常但若出现class com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl$DocumentBuilderImpl这类明显无关的类名或抛出java.lang.ClassNotFoundException: javax.servlet.http.Part则100%是类路径污染。此时检查mvn dependency:tree -Dincludesjavax.servlet定位冲突依赖。3.2 第二步模拟InputStream未耗尽场景编写一个故意“半途而废”的上传方法PostMapping(/dangerous-upload) public String dangerousUpload(RequestParam(file) MultipartFile file) throws IOException { InputStream is file.getInputStream(); // 错误示范只读前10字节就放弃 byte[] buffer new byte[10]; int len is.read(buffer); // 此处读取后is未close指针停在第11字节 System.out.println(Read len bytes); // 业务逻辑...假设这里发生异常或return return Partial read done; }调用此接口后立即检查系统临时目录Spring默认为java.io.tmpdir可通过System.getProperty(java.io.tmpdir)获取。你会看到类似upload_1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2t3u4v5w6x7y8z9a0b1c2d3e4f5g6h7i8j9k0l1m2n3o4p5q6r7s8t9u0v1w2x3y4z5a6b7c8d9e0f1g2h3i4j5k6l7m8n9o0p1q2r3s4t5u6v7w8x9y0z1a2b3c4d5e6f7g8h9i0j1k2l3m4n5o6p7q8r9s0t1u2v3w4x5y6z7a8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3a4b5c6d7e8f9g0h1i2j3k4l5m6n7o8p9q0r1s2......的超长文件名Tomcat 10生成的Jakarta Part临时文件名特征。用lsof -p pid | grep uploadLinux或handle.exe -p pid | findstr uploadWindows Sysinternals可确认该文件是否被Java进程句柄锁定。3.3 第三步验证cleanup失败的直接证据在application.properties中开启Spring MVC详细日志logging.level.org.springframework.web.multipart.supportDEBUG logging.level.org.apache.catalina.coreDEBUG重启应用再次上传。观察DEBUG日志中是否有类似DEBUG o.s.w.m.s.StandardServletMultipartResolver - Cleaning up multipart items for request ... DEBUG o.a.c.c.CoyoteAdapter - The variable [uri] has value [/upload] WARN o.s.w.m.s.StandardServletMultipartResolver - Failed to perform cleanup of multipart items关键点在于WARN之前必须有DEBUG级别的“Cleaning up”日志——这证明Spring确实执行了cleanup逻辑但delete()调用失败。若连DEBUG日志都不出现则问题更底层可能是DispatcherServlet未正确注册或请求根本未进入Multipart处理链路如Content-Type非multipart/form-data。4. 终极解决方案四套生产级修复策略含代码模板4.1 策略一强制统一Jakarta依赖治本之策这是最彻底的方案适用于新项目或可接受重构的旧项目。核心是*确保整个类路径下javax.servlet.完全消失。在pom.xml中添加Maven Enforcer插件强制检查plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version3.4.1/version executions execution idenforce-no-javax-servlet/id goals goalenforce/goal /goals configuration rules bannedDependencies excludes excludejavax.servlet:*/exclude excludejavax.servlet.jsp:*/exclude excludejavax.el:*/exclude /excludes message禁止使用javax.servlet相关依赖请迁移到jakarta.*/message /bannedDependencies /rules /configuration /execution /executions /plugin同时将所有servlet相关依赖显式声明为jakarta版本dependency groupIdjakarta.servlet/groupId artifactIdjakarta.servlet-api/artifactId scopeprovided/scope /dependency dependency groupIdjakarta.servlet.jsp/groupId artifactIdjakarta.servlet.jsp-api/artifactId scopeprovided/scope /dependency dependency groupIdjakarta.el/groupId artifactIdjakarta.el-api/artifactId scopeprovided/scope /dependency对于无法升级的第三方jar如某银行SDK采用Shade Plugin重写包名plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-shade-plugin/artifactId version3.4.1/version executions execution phasepackage/phase goals goalshade/goal /goals configuration relocations relocation patternjavax.servlet./pattern shadedPatternshaded.jakarta.servlet./shadedPattern /relocation /relocations /configuration /execution /executions /plugin此方案实施后StandardServletMultipartResolver的Part.delete()调用将100%成功因为反射目标类与实例类型完全匹配。4.2 策略二InputStream安全消费模式防御性编程无论API版本如何InputStream未耗尽都是高频雷区。必须建立“获取即消费”铁律。推荐以下三种安全模式模式Atry-with-resources IOUtils完全读取推荐PostMapping(/safe-upload) public String safeUpload(RequestParam(file) MultipartFile file) throws IOException { // 关键用try-with-resources确保流关闭 try (InputStream is file.getInputStream()) { // 强制读取全部内容到内存适合小文件10MB byte[] bytes IOUtils.toByteArray(is); // 后续业务逻辑使用bytes不再碰is processFileBytes(bytes, file.getOriginalFilename()); return Success; } // 此处自动调用is.close() }模式BStreaming到目标位置大文件首选PostMapping(/stream-upload) public String streamUpload(RequestParam(file) MultipartFile file) throws IOException { String targetPath /data/uploads/ file.getOriginalFilename(); try (InputStream is file.getInputStream(); FileOutputStream os new FileOutputStream(targetPath)) { // 直接流式传输零内存拷贝 IOUtils.copy(is, os); // 文件已落盘临时文件可安全清理 return Saved to targetPath; } }模式C校验式读取防编码陷阱PostMapping(/robust-upload) public String robustUpload(RequestParam(file) MultipartFile file) throws IOException { try (InputStream is file.getInputStream()) { // 先探测BOM头避免IOUtils.toString因编码错误中断 byte[] bom new byte[3]; int read is.read(bom); if (read 3 bom[0] (byte) 0xEF bom[1] (byte) 0xBB bom[2] (byte) 0xBF) { // UTF-8 BOM存在跳过 is.skip(3); } // 此时再安全读取 String content IOUtils.toString(is, StandardCharsets.UTF_8); return Content length: content.length(); } }提示永远不要在Controller中仅调用MultipartFile.getBytes()或MultipartFile.getSize()就结束——这两个方法不消耗InputStream只是返回元数据。4.3 策略三自定义MultipartResolver绕过原生缺陷当无法修改依赖或需精细控制时可继承StandardServletMultipartResolver并重写cleanup逻辑Component public class RobustMultipartResolver extends StandardServletMultipartResolver { Override protected void cleanupMultipart(MultipartHttpServletRequest request) { try { super.cleanupMultipart(request); // 先执行父类逻辑 } catch (Exception e) { // 捕获父类静默忽略的异常 logger.error(Critical cleanup failure, forcing manual delete, e); forceDeleteTempFiles(request); } } private void forceDeleteTempFiles(MultipartHttpServletRequest request) { HttpServletRequest servletRequest request.getRequest(); try { CollectionPart parts servletRequest.getParts(); for (Part part : parts) { // 尝试多种删除方式 try { part.delete(); // 原生方式 } catch (Exception ignore) {} // 备用获取临时文件路径手动删除 Field fileField part.getClass().getDeclaredField(file); fileField.setAccessible(true); File tempFile (File) fileField.get(part); if (tempFile ! null tempFile.exists()) { FileUtils.forceDelete(tempFile); // Apache Commons IO } } } catch (Exception e) { logger.error(Failed to force delete temp files, e); } } }此方案通过反射获取Part内部持有的File对象即使delete()失败也能用FileUtils.forceDelete()强制清理彻底杜绝磁盘占用。4.4 策略四容器层兜底清理运维级保障在应用层修复的同时必须部署系统级防护。在Linux服务器上创建定时任务# /etc/cron.d/cleanup-spring-temp # 每小时清理72小时内未修改的spring临时文件 0 * * * * root find /tmp -name upload_* -mmin 4320 -delete 2/dev/nullWindows Server则用PowerShell脚本# cleanup-spring-temp.ps1 $TempDir $env:TEMP $Files Get-ChildItem $TempDir\upload_* -ErrorAction SilentlyContinue foreach ($file in $Files) { if ($file.LastWriteTime -lt (Get-Date).AddHours(-72)) { Remove-Item $file.FullName -Force } }设置为计划任务每2小时执行一次。这虽不能解决根本问题但能防止临时文件堆积导致磁盘爆满——我服务过的三个大型电商平台都靠此方案扛过了紧急上线期。5. 避坑指南那些年我们踩过的“标准”陷阱附真实案例5.1 陷阱一“Spring Boot Starter Web已包含所有依赖”幻觉很多开发者认为只要引入spring-boot-starter-webServlet API就万事大吉。实则不然。Spring Boot 2.6默认使用Tomcat 10其servlet-api坐标是jakarta.servlet:jakarta.servlet-api但若项目中存在spring-boot-starter-tomcat的旧版传递依赖如1.5.xMaven可能解析出javax.servlet:javax.servlet-api。我在一个政务云项目中遇到此问题客户要求必须用Spring Boot 2.5.14LTS版本而该版本默认依赖Tomcat 9.0.56javax版但客户提供的PaaS平台强制注入Tomcat 10.1.12jakarta版结果应用启动时ClassLoader加载冲突报错java.lang.NoClassDefFoundError: javax/servlet/ServletContext。解决方案不是降级Tomcat而是显式排除冲突依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId scopeprovided/scope /dependency5.2 陷阱二RequestBody与MultipartFile混用引发的流劫持当Controller方法同时声明RequestBody MyDto dto和RequestParam(file) MultipartFile file时Spring会先解析JSON体再解析multipart。但RequestBody解析器如Jackson会一次性读取整个HttpServletRequest.getInputStream()导致后续MultipartFile.getInputStream()返回空流或IOException。我曾调试一个合同签署接口前端传JSON元数据PDF文件本地测试正常上线后PDF总为空。抓包发现Nginx配置了client_max_body_size 100m而Spring的spring.servlet.multipart.max-request-size10MB当JSONPDF总大小超10MB时Spring的MultipartFilter在解析前就因请求体过大而截断但错误日志被吞没只留下那行cleanup失败报错。解决方案永远不要在同一个请求中混用RequestBody和MultipartFile改用DTO封装public class ContractUploadRequest { private String contractId; private String signatory; private MultipartFile pdfFile; // 作为DTO字段非RequestParam }并在Controller中用ModelAttribute接收确保Spring统一解析。5.3 陷阱三单元测试中的临时文件幽灵JUnit 5测试中若使用MockMvc模拟文件上传MockMultipartFile对象在测试结束后不会触发cleanup因为其Part实现是内存对象无delete()逻辑。但开发者常误以为它会像真实请求一样创建临时文件。结果是大量测试用例运行后/tmp目录塞满mock-multipart-*文件。解决方案在测试类中添加AfterEach钩子AfterEach void cleanupMockFiles() { try { Files.walk(Paths.get(System.getProperty(java.io.tmpdir))) .filter(path - path.toString().contains(mock-multipart)) .forEach(path - { try { Files.deleteIfExists(path); } catch (IOException e) { // 忽略删除失败 } }); } catch (IOException e) { // 忽略遍历异常 } }5.4 陷阱四云环境下的临时目录权限迷雾在Kubernetes Pod中若容器以非root用户运行安全最佳实践而Spring的java.io.tmpdir指向/tmpPod内默认可写但某些云厂商的Runtime如AWS EKS的Bottlerocket OS会将/tmp挂载为只读tmpfs。此时StandardServletMultipartResolver创建临时文件失败直接抛java.io.IOException: Permission denied但Spring捕获后仍输出那行cleanup失败日志掩盖了真正的权限问题。诊断命令# 进入Pod kubectl exec -it pod-name -- sh # 检查/tmp挂载属性 mount | grep tmp # 检查/tmp权限 ls -ld /tmp # 检查当前用户对/tmp的写权限 touch /tmp/test rm /tmp/test解决方案在application.yml中强制指定可写临时目录spring: servlet: multipart: location: /app/tmp # 挂载一个可写emptyDir卷到此路径并在Deployment中添加卷声明volumeMounts: - name: tmp-volume mountPath: /app/tmp volumes: - name: tmp-volume emptyDir: {}6. 实战复盘从日志报警到根治的完整时间线某电商大促案例去年双十二前两周我们负责的订单图片上传服务开始出现间歇性超时。监控显示服务器磁盘使用率每小时上涨0.5%72小时后达到95%阈值。SRE团队发来告警日志片段第一行就是那句熟悉的“Failed to perform cleanup of multipart items”。我的排查时间线如下Day 1定位阶段用df -h确认/tmp分区占满ls -lt /tmp | head -20看到数百个upload_开头的GB级文件执行lsof -p $(pgrep -f java.*OrderUpload) | grep upload发现23个文件被Java进程句柄锁定检查mvn dependency:tree | grep servlet发现支付SDK引入javax.servlet-api:4.0.1而Spring Boot 2.6.13自带jakarta.servlet-api:4.0.4Day 2验证阶段在测试环境部署补丁排除javax依赖强制使用jakarta版本编写压力测试脚本模拟100并发上传20MB图片持续1小时结果/tmp目录文件数量稳定在5个以内Tomcat默认maxUploadSizePerFile20MB临时文件数≈并发数且lsof无upload文件残留Day 3灰度发布制作热修复包仅更新pom.xml依赖不改动业务代码在20%流量的灰度集群部署监控磁盘增长速率数据灰度集群磁盘每小时增长0.02%主集群仍为0.5% → 确认修复有效Day 4全量与加固全量发布热修复包同步上线容器层清理脚本每30分钟扫描删除2小时以上临时文件在CI/CD流水线中加入Enforcer插件阻断任何javax.servlet依赖合入最终大促期间该服务0磁盘告警上传成功率99.997%3个失败均为网络超时与文件清理无关。这个案例印证了一个事实90%的“StandardServletMultipartResolver cleanup失败”问题根源不在Spring框架本身而在开发者对Servlet生命周期和Java IO模型的理解偏差。当你看到那行报错时不要急着搜解决方案先问自己三个问题我的项目里有没有javax和jakarta两个Servlet API共存我的Controller方法中是否每个MultipartFile.getInputStream()都被try-with-resources包裹我的测试环境和生产环境临时目录的权限和挂载方式是否一致这三个问题的答案往往比任何Stack Overflow答案都更接近真相。我自己在实际操作中发现只要在Controller方法签名中看到MultipartFile参数第一反应就该是检查其InputStream的消费逻辑——这已成为我代码审查的肌肉记忆。最后再分享一个小技巧在开发阶段给StandardServletMultipartResolver加一层包装Bean重写cleanupMultipart方法在其中添加logger.info(Cleanup triggered for request {}, request.getRequestURL())这样每次请求结束都能在日志中看到cleanup是否被调用比等报错再排查高效十倍。