Path接口解决了File类路径操作语义模糊、跨平台不一致、职责混杂等问题：提供纯路径抽象，自动适配分隔符，支持归一化、相对化等安全运算，并与Files解耦实现可预测I/O。
Path接口解决了File类的哪些设计缺陷
Java 7 引入 Path 接口（属于 java.nio.file）核心是为替代老旧的 java.io.File 类——后者把路径操作、元数据访问、I/O 行为全混在一个类里，导致语义模糊、不可扩展、跨平台行为不一致。
典型问题包括：File.getAbsolutePath() 在 Windows 返回带盘符的路径，在 Linux 却可能返回冗余的 /./；File.renameTo() 跨文件系统失败却不抛明确异常；File.list() 无法过滤或控制遍历深度。
-
Path是纯路径抽象，不涉及 I/O 或文件存在性判断，职责单一 - 所有路径运算（拼接、归一化、相对化）由
Paths.get()和Path.resolve()等方法显式完成，结果可预测 - 路径分隔符自动适配系统：
Paths.get("a", "b", "c")在 Windows 生成a\b\c，Linux 下生成a/b/c - 支持 URI 构造和解析：
Paths.get(URI.create("file:///tmp/data.txt"))可直接转为Path
为什么不能直接用String拼接路径
硬拼 "dir" + File.separator + "file.txt" 看似可行，但极易出错：多层 File.separator 混用导致重复分隔符；未处理空字符串或开头的 "./"；Windows 下大小写不敏感但路径字符串本身区分大小写，造成逻辑误判。
Path 提供语义安全的操作：
立即学习“Java免费学习笔记（深入）”；
-
Path.resolve(String)：将字符串作为“子路径”追加，自动跳过冗余分隔符 -
Path.relativize(Path)：计算两个路径间的相对关系，结果符合 POSIX/Linux/Windows 各自规范 -
Path.normalize()：消除"./"、"../"和重复分隔符，如"a/../b/./c"→"b/c"
Path base = Paths.get("/home/user");
Path target = base.resolve("docs/../downloads/file.zip").normalize();
// 结果恒为 /home/user/downloads/file.zip，与系统无关
Files工具类和Path如何配合使用
Path 本身不执行读写，真正做 I/O 的是静态工具类 Files。这种分离让路径构造与文件操作解耦，也便于测试（比如 mock Path 实例传给方法，无需真实磁盘）。
-
Files.exists(path)判断路径是否对应真实文件或目录 -
Files.walk(path)返回惰性流，可限制深度、过滤类型，比File.listFiles()更可控 -
Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING)显式声明覆盖语义，避免File.renameTo()静默失败 - 注意：
Files.readAllLines(path)默认用 UTF-8，若文件是 GBK 编码会乱码，必须显式传StandardCharsets.GBK
常见陷阱：toFile() 和 toString() 的误用
Path.toString() 返回的是路径字符串表示（如 "C:\temp\log.txt"），不是文件系统路径；而 Path.toFile() 会创建一个 File 对象——这一步就退回到了旧模型，失去 Path 的优势，且在某些 JDK 版本中可能触发不兼容行为（如 UNC 路径处理异常）。
- 永远优先用
Files.*方法操作Path，而非转成File -
Path.getParent()可能返回null（如Paths.get("a.txt")），调用前需判空 - 路径比较要用
Objects.equals(p1, p2)或p1.equals(p2)，不要用==或String的equals() - 绝对路径判断用
Path.isAbsolute()，别依赖字符串首字符是否为'/'或'C:'
最易被忽略的一点：Path 实例是不可变的，所有 resolve、relativize 等方法都返回新实例——这点和 String 类似，但开发者常误以为原对象已被修改。
