Files.exists 默认跟随符号链接，检查目标路径是否存在；若需确认符号链接自身存在，须显式传入 LinkOption.NOFOLLOW_LINKS。
Files.exists 对符号链接的默认行为是什么
Files.exists 默认会**跟随符号链接**（follow links），也就是说，它检查的是符号链接所指向的目标路径是否存在，而不是符号链接文件本身。如果你用 Paths.get("/path/to/symlink") 调用 Files.exists，只要目标文件存在，就返回 true；如果目标被删了，哪怕符号链接还在，也会返回 false。
这在多数场景下是合理的，但容易误判：你本想确认“这个符号链接文件是否创建成功”，结果却在验证它的目标。
- 符号链接本身损坏（dangling）→
Files.exists(path)返回false - 符号链接指向一个权限不足的目录 → 可能抛
AccessDeniedException，而非返回false - 想区分“链接存在”和“链接有效”时，这个默认行为就不够用了
用 LinkOption.NOFOLLOW_LINKS 显式跳过解析
要真正检查符号链接文件自身是否存在（即 inode 是否存在、路径是否可访问），必须传入 LinkOption.NOFOLLOW_LINKS：
Path p = Paths.get("/path/to/symlink");
boolean existsAsLink = Files.exists(p, LinkOption.NOFOLLOW_LINKS);
这时 Files.exists 不会尝试读取或解析链接目标，只检查该路径是否是一个有效的、可访问的文件系统条目（包括普通文件、目录、符号链接、甚至挂载点等）。
- 即使链接目标不存在（dangling），只要符号链接文件本身没被删，
existsAsLink就是true - 如果路径根本不存在，或父目录不可读，仍返回
false - 注意：Windows 上对符号链接支持有限，某些旧版本 JDK 可能静默忽略
NOFOLLOW_LINKS
如何安全判断“链接存在且目标可达”
单独用 Files.exists 无法同时满足两个条件。常见做法是分两步，但要注意顺序和异常处理：
- 先用
Files.exists(p, LinkOption.NOFOLLOW_LINKS)确认链接文件存在 - 再用
Files.exists(p)（无选项，默认跟随）确认目标可达 - 中间可能抛出
IOException（如权限问题）、SecurityException（安全管理器限制），不能只靠布尔值 - 避免竞态：两次调用之间链接可能被删除或重写，生产环境建议加锁或接受短暂不一致
示例逻辑：
try {
boolean isLinkPresent = Files.exists(p, LinkOption.NOFOLLOW_LINKS);
boolean isTargetReachable = isLinkPresent && Files.exists(p);
} catch (IOException e) {
// 处理访问异常，比如父目录无读权限
}
Files.isSymbolicLink 比 exists 更适合类型判断
如果你真正关心的是“这个路径是不是个符号链接”，不要依赖 Files.exists 的返回值做推断。直接用 Files.isSymbolicLink：
Path p = Paths.get("/path/to/thing");
if (Files.isSymbolicLink(p)) {
// 是符号链接，不管它是否 dangling
} else if (Files.exists(p)) {
// 是普通文件或目录，且存在
}
这个方法内部也使用 NOFOLLOW_LINKS，但它专注语义——只回答“是不是链接”，不涉及存在性或可达性。混用 exists 和 isSymbolicLink 时，记得它们的语义边界：前者是“能不能访问到某物”，后者是“这个东西的类型是什么”。
符号链接的处理难点不在 API 多少，而在“存在”这个词在不同上下文里指代的对象完全不同：是路径节点？是目标文件？还是可读性？每次调用前，得先问清楚自己到底在查什么。
