filesystemexception 的精准诊断应依赖 e.getreason() 和 e.getfile()：前者提供跨平台一致的原生错误描述，后者返回触发异常的绝对路径，二者共同构成稳定、可操作的故障定位依据。
FileSystemException 本身不直接暴露操作系统错误码（如 Linux 的 errno 或 Windows 的 GetLastError() 值），但它通过标准化接口提供了足够精准的诊断依据——关键不在“错误码数字”，而在 e.getReason() 和 e.getFile() 这两个不可替代的信息源。
为什么不用 errno 或 GetLastError？
Java NIO.2 的设计原则是跨平台抽象，JVM 层已将底层系统错误映射为人类可读的字符串描述，并封装进 FileSystemException。硬解码 errno（比如看到 "Permission denied" 就认为是 13）既无必要，也易出错：不同系统对同一语义操作返回的 errno 可能不同，且 JVM 不保证透传原始值。真正稳定、可依赖的是异常实例自带的语义化信息。
getReason() 是最准的“错误码替代品”
e.getReason() 返回操作系统原生的错误描述短语，它比 getMessage() 更纯净、更一致：
- Linux/macOS 常见值："Permission denied"、"No such file or directory"、"Directory not empty"、"Device or resource busy"
- Windows 常见值："Access is denied"、"The process cannot access the file because it is being used by another process"、"The directory is not empty"
- 该字段内容不受 JVM 拼接干扰，也不含路径或额外上下文，适合做精确字符串匹配
getFile() 定位真实出问题的路径
e.getFile() 返回的是触发异常时 OS 实际访问的**绝对路径**（不是你传入的相对路径或符号链接本身）。这个路径可用于：
- 日志中直接记录，方便运维人员在对应机器上手动验证（如
ls -ld /path/to/dir或icacls "C:\path\to\file"） - 自动调用
Files.exists()、Files.isWritable()等预检方法复现状态 - 区分“目标路径不存在”和“父目录不可写”——例如
Files.createDirectory(path)失败时，e.getFile()往往指向父目录而非你要建的子目录
不推荐的“伪精准”做法
以下方式看似想挖更深，实则引入不确定性：
- 试图从
e.getMessage()中正则提取数字（如匹配\d+）——该字符串格式不稳定，Windows 和 Linux 差异大，且可能包含行号、时间戳等干扰项 - 用
instanceof FileSystemException做粗粒度判断后就不再解析原因——同一个异常类型覆盖十几种场景，权限拒绝和文件被占用必须区别处理 - 依赖 SecurityManager 或 AccessController 检查权限——它们反映的是 Java 安全策略，不是实际 OS 文件权限，常出现“策略允许但 OS 拒绝”的误判
