不能继续用 File 拼路径，因其硬拼字符串易出错（如 Windows 反斜杠转义）、跨文件系统操作失败静默、路径处理能力弱；Path+Files 提供平台适配、符号链接支持、原子操作、流式读写等 File 不具备的核心能力。
为什么不能继续用 File 拼路径？
不是“不推荐”，而是硬拼字符串在真实项目里大概率出错：new File("C:\temp\log.txt") 在 Windows 下反斜杠被当转义符，实际变成 C: emp\log.txt，路径错乱却无任何异常；file.renameTo(another) 跨文件系统失败时只返回 false，不抛异常，逻辑卡死难排查。
- 用
Paths.get("a", "b", "c")自动适配平台分隔符（Windows 用\，Unix 用/） - 拼路径必须用
p.resolve("sub")，不是p.toString() + "/sub" - 消除冗余路径段：用
p.normalize()把a/../b变成b，避免isDirectory()判断失败
Files.exists() 和 file.exists() 行为完全不同
Files.exists(p) 是 NIO 语义的、可预测的检查：它统一抛 NoSuchFileException（继承自 IOException），对符号链接行为一致；而 file.exists() 是老式黑盒判断，遇到符号链接可能返回 false 却不告诉你原因，且不区分“不存在”和“无权限访问”。
- 检查前先确认是普通文件：
Files.isRegularFile(p)，比file.isFile()更可靠 - 要读配置文件，别只看
exists()，还得加Files.isReadable(p)和Files.isRegularFile(p) - 永远别写
p.toFile().exists()—— 这等于绕过 NIO，重蹈旧坑
哪些操作 File 根本做不到，只能靠 Path+Files？
不是“更方便”，而是能力断层：File 类没有等价实现，某些需求下它就是无解。
