文件上传失败时清理临时文件的关键是确保异常或正常情况下均能删除，应使用try-finally或try-with-resources实现资源确定性释放，并在finally或close()中判空删除、记录警告；spring中建议transferto可控路径后手动清理，异步场景需结合ttl、job id和原子操作保障可靠性。
文件上传失败时清理临时文件，关键在于确保无论是否发生异常，临时文件都能被及时删除。Java 提供了多种可靠方式来实现这一点，核心思路是“资源确定性释放”——不能只依赖 try 中的正常流程，必须把清理逻辑放在 finally 或使用自动资源管理（try-with-resources）中。
用 try-finally 保证清理执行
这是最直接、兼容性最好的方式。即使 upload() 抛出异常，finally 块仍会执行，可安全调用 delete()。
- 先创建临时文件（如 Files.createTempFile()），保存其路径或 File 引用
- 在 try 块中执行实际上传逻辑（如写入远程存储、校验、重命名等）
- 在 finally 块中检查临时文件是否存在，存在则调用 delete() 或 deleteOnExit()（注意：deleteOnExit 仅适合 JVM 退出前清理，不适用于 Web 请求级临时文件）
示例片段：
File tempFile = null;
try {
tempFile = Files.createTempFile("upload-", ".tmp").toFile();
// 将请求流写入 tempFile
// 调用第三方 SDK 上传 tempFile → 可能抛 IOException / RuntimeException
} catch (IOException e) {
throw new UploadException("上传失败", e);
} finally {
if (tempFile != null && tempFile.exists()) {
boolean deleted = tempFile.delete();
if (!deleted) {
// 记录警告：临时文件删除失败，可能需后续巡检
log.warn("无法删除临时文件: {}", tempFile.getAbsolutePath());
}
}
}
用 try-with-resources 管理可关闭的临时资源
如果临时文件是通过 OutputStream 或自定义的 AutoCloseable 包装器写入的，可以将“写入过程”和“清理动作”封装进一个可关闭资源中。
- 定义一个 TempFileResource 类，实现 AutoCloseable，在 close() 中执行删除
- 在 try-with-resources 中使用它，JVM 保证 close() 在异常或正常结束时都会被调用
- 注意：close() 内部仍需判空和捕获 delete 异常，避免影响原有异常传播
Spring MVC 场景下结合 MultipartFile 的处理建议
使用 MultipartFile 时，它的 transferTo(File) 方法本身就会把内容落地为临时文件（Servlet 容器管理）。此时清理时机更需谨慎：
- 不要直接依赖 MultipartFile 自动清理（部分容器在请求结束后才删，不可控）
- 推荐做法：立即 transferTo 到你可控的临时路径（如 /tmp/upload-xxx），再上传到目标存储；上传成功后再删，失败也在 finally 删
- 若使用 StandardServletMultipartResolver，可通过 setResolveLazily(true) 延迟解析，配合手动清理更灵活
补充：异步上传或分布式环境下的注意事项
如果上传逻辑涉及异步线程或跨服务调用，临时文件生命周期不能只靠单次请求上下文保障：
- 给临时文件加时间戳或 TTL 标识，搭配后台定时任务扫描并清理超时未完成的文件
- 上传前生成唯一 job ID，将临时文件名与 job ID 绑定，失败时可通过 ID 精准清理
- 避免在共享存储（如 NFS）上直接 delete，要考虑并发冲突，可用原子 rename + 定期清理归档目录的方式提升可靠性
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
