当使用 UrlResource 返回静态文件时，若文件不存在，Spring 在响应写入阶段（非控制器执行阶段）会抛出 FileNotFoundException，该异常发生在 ResourceHttpMessageConverter 中，因此无法被控制器内的 try-catch 捕获；需在构造 UrlResource 前主动校验文件存在性。
当使用 `urlresource` 返回静态文件时，若文件不存在，spring 在响应写入阶段（非控制器执行阶段）会抛出 `filenotfoundexception`，该异常发生在 `resourcehttpmessageconverter` 中，因此无法被控制器内的 `try-catch` 捕获；需在构造 `urlresource` 前主动校验文件存在性。
在 Spring Boot 中，ResponseEntity<resource></resource> 的返回看似在控制器方法内完成，实则资源的实际内容长度检查、HTTP 头设置及序列化由 ResourceHttpMessageConverter 在视图渲染/消息转换阶段异步触发——此时控制器方法早已执行完毕，try-catch 作用域已退出。这就是为何 FileNotFoundException 总是绕过你的 catch (Exception e)，最终以 500 Internal Server Error 形式暴露给客户端。
根本解决方式是：在创建 UrlResource 实例前，显式验证目标文件是否存在。UrlResource 构造本身不检查文件存在性，但其后续调用 contentLength()（用于设置 Content-Length 头）会触发 AbstractFileResolvingResource 的底层 Files.exists() 检查——而该检查失败即抛出未捕获异常。
以下是修复后的控制器代码（关键改动已加注释）：
@GetMapping("analysis/daily/{year}/{month}/{day}/{mode}")
public ResponseEntity<resource> getDailyAnalysis(
@PathVariable("year") int year,
@PathVariable("month") int month,
@PathVariable("day") int day,
@PathVariable("mode") AnalysisSelection type) {
Path fileBasePath = Path.of("Analysis", "ZIP", "Daily",
String.valueOf(year),
String.valueOf(month),
String.valueOf(day));
// 1. 根据 type 确定具体文件名，并构建完整路径
Path filePath;
switch (type) {
case ByItem -> filePath = fileBasePath.resolve("SingleItemAnalysis.zip");
case ByAuthor -> filePath = fileBasePath.resolve("Author.zip");
case ByType -> filePath = fileBasePath.resolve("Type.zip");
case ByIndustry -> filePath = fileBasePath.resolve("Industry.zip");
default -> throw new ResponseStatusException(HttpStatus.BAD_REQUEST, "Invalid analysis mode");
}
// 2. ⚠️ 关键修复：提前检查文件是否存在
if (!Files.exists(filePath) || !Files.isRegularFile(filePath)) {
throw new ResponseStatusException(HttpStatus.NOT_FOUND,
"Requested analysis file not found: " + filePath);
}
// 3. 此时可安全构造 UrlResource（文件已确认存在）
try {
Resource resource = new UrlResource(filePath.toUri());
return ResponseEntity.ok()
.contentType(MediaType.parseMediaType("application/zip"))
.header(HttpHeaders.CONTENT_DISPOSITION,
"attachment; filename=\"" + resource.getFilename() + "\"")
.body(resource);
} catch (Exception e) {
// 此处的 catch 已非必需（因前置校验已覆盖），但仍建议保留兜底
throw new ResponseStatusException(HttpStatus.INTERNAL_SERVER_ERROR,
"Failed to serve file: " + filePath, e);
}
}</resource>
注意事项与最佳实践：
- ✅ 永远先校验，再构造
UrlResource：Files.exists(path)和Files.isRegularFile(path)是轻量级 I/O 检查，应作为前置守卫。 - ✅ 避免
Path.of(...).toUri()直接传入UrlResource构造器：确保filePath是绝对路径且指向真实文件；若路径基于相对路径（如项目根目录），建议通过ResourceLoader或ServletContext获取基础目录，提升可移植性。 - ⚠️ 不要依赖
resource.exists()：UrlResource.exists()在某些场景下（如file:协议）可能返回false即使文件存在，因其内部实现有局限；Files.exists()更可靠。 - ? 权限与安全性：确保 Web 应用对目标目录具有读取权限；生产环境切勿暴露敏感路径（如
..路径遍历），建议对year/month/day参数做范围校验，并规范化路径（如Paths.get(...).normalize()）。 - ? 替代方案（进阶）：对于高频文件服务场景，可考虑使用
FileSystemResource（更可控）或预生成ByteArrayResource（适合小文件），但需权衡内存与 I/O 开销。
通过前置文件存在性校验，你将异常拦截在请求处理早期，精准返回 404 Not Found，既符合 REST 规范，也提升了 API 的健壮性与可观测性。
