Files.exists 默认不追踪符号链接是因为采用 NOFOLLOW_LINKS 语义，仅检查链接文件自身存在性；要检查目标存在需调用无 LinkOption 的重载方法。
Files.exists 为什么默认不追踪符号链接
Files.exists 默认行为是「不跟随符号链接」（即 NOFOLLOW_LINKS），这意味着它只检查链接文件自身是否存在，而不是链接指向的目标路径。如果你用它判断一个符号链接是否“有效”，结果可能为 true（链接文件存在），但实际指向的路径早已被删除——这正是容易误判的地方。
要真正判断符号链接指向的真实文件是否存在，必须显式告诉 Files.exists 去跟随链接，也就是传入 LinkOption.NOFOLLOW_LINKS 的反面：不传该选项（即默认跟随），或更明确地——**不传任何 LinkOption**。
- ✅ 正确做法：直接调用
Files.exists(path)（无参数）→ 跟随符号链接，检查目标是否存在 - ❌ 错误做法：
Files.exists(path, LinkOption.NOFOLLOW_LINKS)→ 只检查链接文件本身，无法得知目标是否有效 - ⚠️ 注意：
LinkOption.NOFOLLOW_LINKS是唯一受支持的LinkOption；传入其他值会抛UnsupportedOperationException
如何区分“链接存在”和“链接目标存在”
实际开发中常需两种判断：一是确认符号链接文件本身是否在磁盘上（比如配置项要求链接必须存在），二是确认它是否指向一个可访问的真实文件（比如加载资源前校验）。这两个场景不能混用同一调用方式。
- 检查链接自身是否存在 →
Files.exists(path, LinkOption.NOFOLLOW_LINKS) - 检查链接最终指向的文件是否存在 →
Files.exists(path)（无LinkOption） - 若想进一步确认路径确实是符号链接 → 先用
Files.isSymbolicLink(path)判断类型，再决定怎么查存在性 - 注意：如果路径是循环链接（如 a → b → a），
Files.exists(path)可能抛FileSystemLoopException，需捕获处理
Java 7+ 中的典型误用示例
下面这段代码看似合理，实则逻辑错误：
Path link = Paths.get("/etc/myconfig.conf");
if (Files.exists(link, LinkOption.NOFOLLOW_LINKS)) {
// ✅ 链接文件存在
if (Files.exists(Files.readSymbolicLink(link))) { // ❌ 危险！readSymbolicLink 可能抛异常，且返回的 Path 未标准化
// …
}
}
问题在于：Files.readSymbolicLink 返回的是原始字符串构建的 Path，可能含 .. 或相对路径，直接传给 Files.exists 易出错；而且多了一次 I/O 和解析开销。
更安全、简洁的做法是：
- 直接用
Files.exists(link)判断目标是否存在（自动跟随 + 解析） - 若需目标的绝对规范化路径，用
link.toRealPath()（它也会自动跟随并检查目标存在性，失败时抛IOException） - 避免手动读取 + 拼接路径，除非你明确需要中间链接路径做审计
跨平台与权限导致的静默失败
Files.exists 在符号链接上的行为虽标准，但实际结果受底层 OS 和权限影响，容易出现“返回 false 却不是因为目标不存在”：
- Linux/macOS：若目标路径存在但当前用户无执行权限（对目录）或读权限（对文件），
Files.exists仍返回false - Windows：NTFS 符号链接（非快捷方式）需管理员权限创建，普通用户创建的可能是 junction 或 shortcut，
Files.isSymbolicLink可能返回false，导致逻辑分支跳过 - 容器环境（如 Docker）：挂载点缺失或
noexec选项可能导致toRealPath()失败，但exists仍返回true（仅检查路径可达性）
所以，单靠 Files.exists 不能完全替代业务层的打开/读取验证——它只是第一道轻量检查。
