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 上会转成 ac 的 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()不做任何检查
Paths.get() 是唯一推荐的起点，其余所有路径拼接、转换、校验都应基于它返回的 Path 对象展开——而不是反复回退到字符串操作。
