FileSystemException 精准定位：分析在多文件系统操作中通过异常变量获取详细的磁盘错误码

处理文件系统异常时，很多开发者下意识地想获取底层的操作系统错误码，比如Linux的errno或Windows的GetLastError()。这种追求“精准”的思路可以理解，但在Ja va NIO.2的语境下，可能走错了方向。FileSystemException的设计哲学是提供跨平台的、语义化的错误信息，而非透传不稳定的底层数字。真正的精准诊断，其实依赖于异常本身提供的两个核心方法：e.getReason()和e.getFile()。

为什么不用 errno 或 GetLastError？

Ja va 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 检查权限——它们反映的是 Ja va 安全策略，不是实际 OS 文件权限，常出现“策略允许但 OS 拒绝”的误判