FileSystemException 是操作系统权限或路径问题，非代码逻辑错误；需通过 getReason() 和 getFile() 定位具体原因，不可依赖 getMessage() 或 instanceof 判断。
FileSystemException 是权限或路径问题，不是代码逻辑错误
Java 抛出 FileSystemException 时，90% 以上和你的程序逻辑无关，而是 JVM 在调用底层 OS 文件 API 时被拒绝了。它本质是 IOException 的子类，但比普通 IO 异常更“具体”——它会附带操作系统原生的错误码和路径信息，比如 Access denied、Directory not empty 或 No such file or directory。
常见触发场景包括：Files.move() 跨文件系统移动、Files.delete() 删除非空目录、Files.createDirectory() 在只读父目录下建子目录。
- Windows 下对正在被记事本/IDE 打开的文件执行
delete()，会报FileSystemException: ... The process cannot access the file because it is being used by another process - Linux/macOS 下用
Files.walkFileTree()遍历挂载点（如/proc），遇到权限不足的子目录直接抛此异常，而非跳过 -
Files.copy()目标路径存在且为只读文件时，不会覆盖，而是抛FileSystemException（取决于StandardCopyOption.REPLACE_EXISTING是否启用）
捕获时必须检查 getReason() 和 getFile()，不能只看异常类型
同一个 FileSystemException 可能对应完全不同的修复方式，只用 instanceof 判断毫无意义。关键信息全在它的两个方法里：
-
e.getReason()返回操作系统原生错误描述（如"Permission denied"），这是最准的诊断依据 -
e.getFile()返回出问题的绝对路径（注意：不是你传入的相对路径），可用于日志定位或人工验证 - 不要依赖
e.getMessage()做判断——它可能被 JVM 拼接过，格式不一致，Windows/Linux 返回内容也不同
示例：处理删除失败时可这样区分
立即学习“Java免费学习笔记（深入）”；
try {
Files.delete(path);
} catch (FileSystemException e) {
String reason = e.getReason();
if ("Permission denied".equals(reason)) {
// 尝试 chmod +w 或检查进程占用
} else if ("Directory not empty".equals(reason)) {
// 改用 Files.walkFileTree() 递归删
}
}
跨平台行为差异大，别假设 Windows 和 Linux 表现一致
同一个操作在不同系统上可能成功、静默失败或抛不同 FileSystemException。根本原因是 Java 的 FileSystem 实现委托给了 OS，而各系统对“非法操作”的定义不同。
-
Files.move(src, dst, ATOMIC_MOVE)：Linux 下若 src/dst 不在同一文件系统，会抛FileSystemException；Windows 下可能静默降级为非原子复制+删除 -
Files.createSymbolicLink()：Linux/macOS 成功，Windows 默认失败（除非启用开发者模式且有管理员权限），抛"Operation not supported" - 路径中含 Unicode 字符：Windows 通常没问题；某些旧版 Linux 内核或挂载选项（如
noexec）会导致"Invalid argument"
建议在 CI 中强制跑多平台测试，尤其涉及 move、createSymbolicLink、setAttribute 等敏感操作。
别用 try-catch 吞掉 FileSystemException，要主动预检
很多团队习惯把文件操作包一层 try/catch 后返回 null 或默认值，这会让问题延迟暴露，甚至掩盖权限配置错误。正确做法是：在执行前用轻量检查降低失败概率。
- 删目录前先
Files.isDirectory(path) && Files.isWritable(path.getParent()) - 写文件前确认
Files.isWritable(path.getParent())，而不是等Files.write()抛异常 - 移动文件前用
path.getFileSystem().isReadOnly()查整个文件系统是否只读（比如 Docker 容器挂载的ro卷） - 注意：这些检查本身也可能抛
SecurityException或IOException，需单独处理，但比事后解析FileSystemException更可控
真正难搞的是“竞态条件”——比如检查时可写，瞬间被其他进程加锁。这种只能靠重试+指数退避，但至少前置检查能筛掉 80% 的静态配置问题。
最麻烦的永远是那些没打日志的 FileSystemException：原因字段为空、路径是临时生成的、堆栈没打印 getFile()。上线前务必确保所有文件操作的日志里都显式输出这两个值。
