FileSystems.getDefault()仅返回默认FileSystem实例，不处理路径；Paths.get()才是跨平台路径构造的关键，自动适配分隔符、规范化路径并支持可变参数。
Java 中 FileSystems.getDefault() 本身不负责“获取跨平台文件系统路径”——它只返回默认的 FileSystem 实例，真正做路径处理的是 Paths.get() 和 Path 类。
为什么 FileSystems.getDefault() 不直接给路径？
这个方法只是个工厂入口，返回当前 JVM 默认的 FileSystem（通常是 sun.nio.fs.WindowsFileSystem 或 sun.nio.fs.UnixFileSystem），它不解析字符串、不拼接路径、也不处理分隔符。路径构造和规范化是 Path 的职责。
常见错误现象：
- 调用 FileSystems.getDefault().getPath("a/b/c") 却发现 Windows 上生成了 ac 而不是预期的正斜杠路径 → 其实这是正常行为，Path 内部已按平台适配；
- 误以为调用它就能“自动跨平台”，结果硬拼字符串 "dir" + File.separator + "file.txt"，绕过了 Path 的语义支持。
-
FileSystems.getDefault()是单例访问点，线程安全，但无状态、无缓存逻辑 - 它的实现类由系统属性
java.nio.file.spi.DefaultFileSystemProvider决定，一般不可替换（除非自定义 provider） - 不要为“跨平台”去判断 OS 再选分隔符——
Paths.get("a", "b", "c")才是正确姿势
Paths.get() 才是路径跨平台的关键入口
所有路径构造应走 Paths.get()，它内部调用 FileSystems.getDefault().getPath()，但封装了标准化逻辑：自动处理分隔符、消除冗余 .. 和 .、统一转义规则。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
使用场景：
- 构建配置文件路径：Paths.get("config", "app.yaml") → Windows 得 configpp.yaml，Linux 得 config/app.yaml；
- 解析用户输入路径时，必须用 Paths.get(input) 而非 new File(input).toPath()（后者不触发规范化）。
- 推荐用可变参数重载：
Paths.get("root", "sub", "file.txt")，比Paths.get("root/sub/file.txt")更安全（避免手动拼接出错） - 若传入绝对路径字符串（如
"C:\data"或"/home/user"），Paths.get()会识别并保留其绝对性 - 注意：空字符串或纯分隔符路径（如
Paths.get("")）会抛InvalidPathException
跨平台路径的三个易踩坑点
真正让路径“跨平台”的不是某个类，而是整套约定和约束。下面三点在 CI/CD 或多环境部署中高频出问题：
立即学习“Java免费学习笔记（深入）”；
- 路径大小写敏感性：Linux/macOS 区分大小写，Windows 默认不区分 →
Paths.get("Config.yaml")在 Windows 可能打开成功，但在 Linux 报No such file - 根路径含义不同：
Paths.get("a").isAbsolute()在 Windows 返回false，而Paths.get("C:\a")才是绝对路径；Linux 下Paths.get("/a")是绝对路径 - 符号链接处理：默认
Path.toFile().exists()不跟随软链，但Files.exists(path, LinkOption.NOFOLLOW_LINKS)才显式控制 —— 这个细节常被忽略，导致路径存在性判断在不同系统上行为不一致
跨平台路径真正的复杂点不在 API 调用，而在路径来源是否受控：配置文件里的硬编码路径、用户输入、环境变量值，这些地方一旦混入平台特定写法（比如 Windows 风格反斜杠或盘符），Paths.get() 也救不回来。
