File类与Path类因抽象层次不同不能直接赋值，但可通过File.toPath()和Path.toFile()互相转换；前者适用于默认文件系统，后者仅支持本地文件系统，跨文件系统时Path更灵活安全。
File 类和 Path 类不能直接赋值，但可以互相转换，关键在于理解它们代表的抽象层次不同：File 是旧 IO 的文件路径抽象，Path 是 NIO.2 更灵活、更语义化的路径抽象。
File → Path
调用 File.toPath() 方法即可，这是最直接、推荐的方式。该方法返回一个默认文件系统的 Path 实例，与原 File 的路径字符串一致，且保留了原始语义（如相对路径、符号链接处理等）。
- 代码示例：Path path = new File("data/config.txt").toPath();
- 注意：返回的 Path 绑定的是
FileSystems.getDefault()，适用于绝大多数场景 - 不建议手动拼接字符串再用
Paths.get()，容易因路径分隔符或空格引发问题
Path → File
调用 Path.toFile() 方法，前提是该 Path 属于默认文件系统（即由 Paths.get() 或 File.toPath() 创建）。否则会抛出 UnsupportedOperationException。
- 代码示例：File file = Paths.get("logs/app.log").toFile();
- 若 Path 来自自定义文件系统（如 ZIP 文件系统），则不能转为 File —— 因为 File 仅支持本地文件系统
- 转换后得到的 File 对象与原始路径逻辑等价，但不继承 Path 的高级操作能力（如 resolve、relativize）
为什么不能无条件互转？
根本原因在于设计目标不同：File 表示“可能存在的文件或目录”，而 Path 是纯路径操作工具，本身不检查是否存在；且 Path 支持多种文件系统（如内存、ZIP、网络），File 则硬编码绑定本地磁盘。
立即学习“Java免费学习笔记（深入）”；
- 跨文件系统时（如访问 jar 包内的资源），Path 可以正常工作，File 无法表示这类资源
- Path 提供更安全的路径解析（如
normalize()、resolve()），File 的getCanonicalPath()易受权限/挂载点影响 - 新代码应优先使用 Path + Files 工具类，File 仅用于兼容遗留 API
实际开发建议
在混合使用场景中（比如调用老接口需要 File，内部逻辑用 Path），按需转换即可，但避免频繁来回转换。
- 读取配置、日志等本地资源时，优先用
Paths.get(...)构造 Path，再用 Files.readAllLines 等方法 - 对接传统库（如 Apache Commons IO、某些框架的 File 参数）时，用
path.toFile()临时适配 - 不要对 Path 做 toString() 后再 new File(...) —— 这会丢失路径语义（如 Windows 路径中的斜杠处理）
