Paths.get() 是创建 Path 的安全方式，应避免 new File().toPath()；多段路径用 Paths.get("a","b","c")，绝对路径勿带尾斜杠，resolve() 追加末段，resolveSibling() 替换末段，toAbsolutePath() 不访问磁盘而 toRealPath() 需路径存在且跨平台行为不一。
直接用 Paths.get() 创建 Path，别碰 new File().toPath() —— 后者绕过系统适配逻辑，跨平台时大概率出错。
Paths.get() 怎么传参才安全
传参方式直接影响路径语义和跨平台行为。错误写法如 Paths.get("/home/user//") 或 Paths.get("data/") 会保留尾随分隔符，后续 resolve() 可能拼出 /home/user//log.txt 这类非法路径。
- 多段路径优先用
Paths.get("a", "b", "c")：自动处理分隔符，Windows 和 Linux 都生成合法路径 - 绝对路径字符串避免末尾斜杠，比如用
Paths.get("/etc")而非Paths.get("/etc/") -
Paths.get("")不是空路径，而是当前工作目录的Path，等价于Paths.get(System.getProperty("user.dir")) - 含中文或空格的路径无需额外转义，
Paths.get("我的文档", "配置.json")可直接用
resolve() 和 resolveSibling() 到底在改哪一段
这两个方法只操作路径的“最后一段”，但逻辑相反，极易混淆。调试时建议先打印原始 Path 的 getNameCount() 和 getFileName() 确认结构。
-
path.resolve("log.txt")：在path末尾追加，无论path是/var/log还是/var/log/app.log，结果都是/var/log/app.log/log.txt -
path.resolveSibling("config.json")：丢弃path的最后一段（即getFileName()），换成新名字；/var/log/app.log.resolveSibling("config.json")→/var/log/config.json - 若
path是根路径（如Paths.get("/")），调用resolveSibling()会抛IllegalArgumentException
toAbsolutePath() 和 toRealPath() 别混用
toAbsolutePath() 是纯字符串补全，不访问磁盘；toRealPath() 是真实 I/O 操作，要求路径存在且可访问，跨平台行为也不一致。
立即学习“Java免费学习笔记（深入）”；
- 仅需补全相对路径？用
toAbsolutePath().normalize()：它能消除..和.，但不解析符号链接 - 要验证路径是否真实可达、是否为符号链接目标？用
toRealPath(LinkOption.NOFOLLOW_LINKS)，但必须包try-catch IOException - Windows 下
toRealPath()对大小写不敏感，Linux 下敏感；若路径来自用户输入，别依赖它做“标准化” - 调试时别用
toRealPath()判断路径“合不合法”——它失败不一定代表路径错，可能只是权限或不存在
真正容易被忽略的是：所有 Path 操作都不检查文件系统是否存在。你拿到一个 Path，它可能指向一个根本不存在的目录，甚至语法上就非法（比如 Windows 下含 < > : " / \ | ? *）。需要真实操作前，务必用 Files.exists() 或 Files.isDirectory() 显式校验。
