Path.getFileSystem() 是合法实例方法，用于获取所属 FileSystem 实例；其配置参数不可直接读取，应通过 getSeparator()、isReadOnly()、supportedFileAttributeViews() 等公开方法间接判断行为特征。
Path.getFileSystem() 不是标准 Java API，无法直接获取文件系统变量配置参数。Java NIO.2 中的 Path 对象本身不提供 getFileSystem() 方法；正确方式是通过 Path.getFileSystem() 的反向调用——即先获得 FileSystem 实例，再创建 Path，而配置参数需从 FileSystem 或其底层实现（如 UnixFileSystem、WindowsFileSystem）中提取，但这些参数通常不对外暴露为可读属性。
正确获取 FileSystem 实例的方式
Java 中 Path 由 FileSystem 创建，因此应从 Path 反查所属文件系统：
- 调用
path.getFileSystem()—— 这才是合法方法（注意：是Path的实例方法，不是静态方法或不存在的Path.getFileSystem()调用） - 该方法返回
java.nio.file.FileSystem抽象类的实例，例如sun.nio.fs.UnixFileSystem（Linux/macOS）或sun.nio.fs.WindowsFileSystem（Windows） - 不同 JVM 实现和操作系统下，具体子类可能不同，且属于内部实现（
sun.*包），不应直接依赖
FileSystem 的配置参数一般不可直接读取
标准 FileSystem 接口未定义“配置参数”访问方法。实际运行时的底层行为（如路径分隔符、大小写敏感性、符号链接处理）由以下方式体现：
-
fileSystem.getSeparator()→ 获取路径分隔符（/或\） -
fileSystem.isReadOnly()→ 判断是否只读（部分实现支持） -
fileSystem.supportedFileAttributeViews()→ 查看支持的属性视图（如"basic","posix","dos"），间接反映系统能力 - 系统属性如
System.getProperty("os.name")和System.getProperty("file.separator")可辅助判断运行环境
若需自定义配置，应使用 FileSystemProvider 或构建自定义 FileSystem
Java 允许注册自定义 FileSystemProvider（如内存文件系统 memoryfilesystem 或测试用 jimfs），此时配置通过 provider 初始化传入：
- 例如
Jimfs.newFileSystem(Configuration.unix())或Configuration.osX()显式指定行为 - 自定义 provider 可在
newFileSystem(URI, Map中接收配置 map，并在) FileSystem实例中保存为私有字段供内部使用 - 但该 map 内容完全由 provider 定义，标准 API 不统一也不暴露
小结：不要试图从 Path 反推“配置参数”
Java NIO 设计上将文件系统行为封装在 FileSystem 实例中，而非以可读参数形式暴露。开发中应：
- 用
path.getFileSystem()获取实例，再调用其公开方法获取行为特征 - 避免反射访问
sun.*类的私有字段（如useCompressedOops等无关字段） - 跨平台逻辑应基于
Files.isSameFile()、Files.exists()等抽象方法，而非硬编码路径规则 - 如需控制行为（如忽略大小写、启用符号链接解析），应在操作时传入对应
LinkOption或使用FileStore查询挂载选项
