怎么利用 FileSystems.getDefault().getPath() 解析跨平台兼容的文件路径字符串

许多人都会误以为 FileSystems.getDefault().getPath() 可以像解析字符串那样直接处理路径，但实际上它根本不接受参数，只返回文件系统的根路径。真正正确且推荐的做法是 Paths.get()，它能跨平台自动适配分隔符，接受逻辑路径字符串并返回 Path 对象。

为什么 FileSystems.getDefault().getPath() 不能直接解析路径字符串

这个方法的本质就不是用来“解析”路径的——它只返回默认文件系统的根路径对象（Path），而且不接受任何参数。如果你尝试写 FileSystems.getDefault().getPath("a/b/c")，编译器会直接报错：no suitable method found for getPath(String)。真正该用的工具是 Paths.get()，它是专门为从字符串构造 Path 设计的跨平台入口，这才是处理路径字符串的正确姿势。

Paths.get() 怎么处理不同操作系统的分隔符

它内部已经自动适配了：Paths.get("a/b/c") 在 Windows 上会转成 a\b\c 的 Path 对象（尽管字符串表示仍显示为 a/b/c），而 Paths.get("a\b\c") 在 Linux 上也能正确识别。关键在于它把输入当作“逻辑路径”，不依赖原始分隔符是否匹配当前系统。

• 推荐始终用正斜杠 / 写死路径字符串（如 "config/app.json"），Paths.get() 能安全处理。
• 避免拼接路径时手动使用 File.separator，那反而会破坏可读性和跨平台一致性。
• 如果必须从用户输入或外部配置读取路径，先通过 String.replace("\\", "/") 统一归一化，再传给 Paths.get()。

和 new File(...).toPath() 有什么实际区别

行为上两者几乎等价，但 Paths.get() 更轻量、语义更清晰，而且不会触发任何文件系统访问（new File(...) 构造本身虽然不访问磁盘，但容易让人误以为它在检查文件存在性）。更重要的是：

• Paths.get() 返回的 Path 支持完整的 NIO.2 操作（如 resolve()、relativize()），而 File.toPath() 返回的对象功能相同，但调用链多一层。
• 某些旧代码里混用 File 和 Path 容易引发类型混淆，统一走 Paths.get() 可以减少这类隐式转换。
• 注意：Paths.get("") 返回的是当前工作目录，不是空路径；Paths.get(".") 才明确表示当前目录。

绝对路径在不同系统上的陷阱

Windows 的绝对路径（如 "C:\temp\log.txt"）传给 Paths.get() 没问题，但如果你写成 "C:/temp/log.txt"，它依然能正确识别驱动器前缀。真正的坑在于相对路径的基准：

• Paths.get("data/file.txt") 总是相对于 JVM 启动时的 user.dir，不是类路径或 jar 包位置。
• 不要假设 Paths.get("../conf/app.conf") 一定有效——上级目录可能不存在，Path 对象本身不校验路径真实性。
• 需要确保路径存在且可访问？得显式调用 Files.exists(path) 或 Files.isReadable(path)，仅靠 Paths.get() 不做任何检查。

跨平台路径的核心不是“怎么写字符串”，而是“用对 API 并理解它的契约”。Paths.get() 是唯一推荐的起点，其余所有路径拼接、转换、校验都应该基于它返回的 Path 对象展开——而不是反复回退到字符串操作。