FileNotFoundException是IOException的受检子类，反映JVM无法以指定方式打开路径，原因包括权限不足、目录误用、符号链接断裂等，不单是文件不存在。
FileNotFoundException 是什么，为什么它总在运行时才爆出来
FileNotFoundException 是 IOException 的子类，属于受检异常（checked exception），编译器强制你处理它。但它又很“假”——名字叫“文件没找到”，实际触发条件远不止路径不存在：权限不足、路径是目录而非文件、符号链接断裂、NFS挂载失效、甚至某些 JVM 在 Windows 上对 UNC 路径解析失败，都会抛这个异常。
关键点在于：它不反映“磁盘上有没有这个文件”，而反映“当前 JVM 进程能否以指定方式（如 new FileInputStream(path)）打开该路径”。所以别只查 ls 或 File.exists() 就以为安全了。
用 try-catch 还是 throws？选错会导致资源泄漏
直接 throws FileNotFoundException 看似省事，但把异常甩给调用方后，往往导致上层忽略或错误吞掉——比如日志没打、用户看到空白页、定时任务静默失败。更危险的是，如果配合 FileInputStream 等资源操作，不加 try-with-resources 会真漏关流。
- 优先用
try-with-resources包裹所有带AutoCloseable的 IO 操作 - 捕获后别空 catch：
catch (FileNotFoundException e) { logger.warn("config file missing, using defaults", e); } - 若必须 throws，请确保调用链最外层（如 Spring Controller、main 方法）有统一兜底处理逻辑
try (FileInputStream fis = new FileInputStream("/etc/app.conf")) {
// 处理配置
} catch (FileNotFoundException e) {
// 明确记录缺失上下文：哪个服务？哪个环境？期望路径是否可配？
throw new IllegalStateException("Critical config missing: /etc/app.conf", e);
}
比 catch 更早一步：用 Files.exists() + Files.isReadable() 预检
File.exists() 不可靠——它不检查权限，也不区分文件/目录；Files.exists(Paths.get(path)) 好些，但仍不够。真正稳妥的预检是组合判断：
立即学习“Java免费学习笔记（深入）”；
-
Files.exists(path)：路径是否存在（含软链目标） -
Files.isRegularFile(path)：确保是普通文件，不是目录或设备 -
Files.isReadable(path)：当前进程是否有读权限（Linux/macOS 有效，Windows 下部分场景可能误报）
注意：这三步不是原子操作，中间仍可能被其他进程删改。预检只降低概率，不能替代 try-catch。
Path configPath = Paths.get("/data/inventory.json");
if (!Files.exists(configPath) ||
!Files.isRegularFile(configPath) ||
!Files.isReadable(configPath)) {
throw new IllegalStateException("Config file invalid: " + configPath);
}
// 此时再 new FileInputStream 才相对安全
常见陷阱：getResourceAsStream() 和 classpath 路径的隐式转换
很多人用 MyClass.class.getResourceAsStream("config.properties") 却仍遇到 FileNotFoundException，问题不在文件本身，而在路径规则：
- 路径以
/开头 → 从 classpath 根开始找（如/static/js/app.js） - 路径不以
/开头 → 相对于当前类所在包（com.example.App调用"config.properties"会去找com/example/config.properties） - 打包成 JAR 后，路径分隔符必须是
/，不能用\（Windows 开发者常在这里翻车）
调试技巧：打印 MyClass.class.getResource("config.properties") 返回的 URL，看它到底指向哪。返回 null 就说明 classpath 里压根没这个资源。
FileNotFoundException 最难缠的地方不是找不到文件，而是“你以为找到了，其实打开方式错了”——比如用 FileReader 读二进制文件、用 Paths.get() 解析含空格的用户输入路径、或者在容器里挂载路径时权限没透传。每次看到这个异常，先别急着补 catch，花 30 秒确认下 ls -l 输出和 Java 进程 UID 是否一致。 
