Java Files.getLastModifiedTime 怎样读取符号链接自身时间

在一次目录同步排查里，我遇到过一个很容易误判的现象：代码明明读取的是符号链接，得到的最后修改时间却和目标文件一致。Java 的默认行为确实如此——Files.getLastModifiedTime(path) 会按通常的链接跟随规则读取目标对象；如果要读取符号链接目录项自身的时间，需要显式传入 LinkOption.NOFOLLOW_LINKS。

官方文档：https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/file/Files.html#getLastModifiedTime(java.nio.file.Path,java.nio.file.LinkOption...)

先问清楚“我要比较的是目标文件，还是链接这个目录项”。比较目标文件时使用默认调用；比较链接自身时使用 LinkOption.NOFOLLOW_LINKS。两种写法都返回 FileTime，差别在于属性归属对象。

• 默认调用：沿着符号链接找到目标对象，再读取目标对象的最后修改时间。
• 读取链接自身：传入 LinkOption.NOFOLLOW_LINKS，不跟随符号链接。
• 故障边界：失效链接、权限不足和文件系统不支持都可能让调用抛出 IOException。
• 封装建议：把“目标时间”和“链接时间”做成两个有名字的方法，别让调用方猜参数。

时间戳看起来不对，影响面通常在哪里

问题往往出在“路径”被当成了“文件本体”。符号链接只是一个目录项，它保存着指向目标的关系；当同步程序、缓存清理器或变更检测器把链接路径传给默认的 getLastModifiedTime 时，API 会按默认规则继续解析目标。于是链接目标刚刚更新，程序就会把这次更新时间归到链接路径上。

这不是 FileTime 精度不够，也不一定是操作系统把时间改乱了。更常见的根因是比较对象没有写进接口契约：一边想判断目标内容是否变化，另一边却拿链接目录项的状态做审计。排查时先记录路径是否为符号链接，再决定后续读取哪个对象。

Java Files.getLastModifiedTime 默认为什么读到目标文件时间

getLastModifiedTime 的参数是路径和可选的 LinkOption。不传选项时，可以把它理解为“按默认文件系统语义解析这个路径”，符号链接会被跟随，返回目标对象的最后修改时间。返回类型是 FileTime，适合继续做时间比较或转成指定时区的展示文本。

import java.io.IOException;
import java.nio.file.FileTime;
import java.nio.file.Files;
import java.nio.file.Path;

static FileTime readTargetTime(Path linkPath) throws IOException {
    // 不传 NOFOLLOW_LINKS：符号链接会按默认规则跟随到目标对象。
    return Files.getLastModifiedTime(linkPath);
}

这段写法适合“目标文件何时更新”这样的任务，例如判断同步源是否有新内容。它不适合用来回答“这个链接目录项何时被修改”，因为调用的语义本来就没有停在链接自身。

读取符号链接自身，要把 NOFOLLOW_LINKS 写出来

LinkOption.NOFOLLOW_LINKS 的含义很直接：不要跟随符号链接。把它传给同一个方法后，读取对象从目标文件切换为链接目录项本身。下面的封装把两种语义并排放出来，调用处不必靠注释猜测。

import java.io.IOException;
import java.nio.file.FileTime;
import java.nio.file.Files;
import java.nio.file.LinkOption;
import java.nio.file.Path;

static FileTime readLinkTime(Path linkPath) throws IOException {
    // NOFOLLOW_LINKS：只读取符号链接这个目录项的属性，不进入目标文件。
    return Files.getLastModifiedTime(linkPath, LinkOption.NOFOLLOW_LINKS);
}

static FileTime readTime(Path path, boolean linkItself) throws IOException {
    // 用布尔参数集中表达策略，避免调用方在多处重复拼接选项。
    return linkItself
            ? Files.getLastModifiedTime(path, LinkOption.NOFOLLOW_LINKS)
            : Files.getLastModifiedTime(path);
}

注意，NOFOLLOW_LINKS 只改变链接解析方式，不会把返回值变成字符串，也不会自动比较两个时间。若业务需要比较，应先确定两边都采用同一种对象语义，再调用 FileTime.compareTo 或转换成统一单位。

一次排查应按什么顺序确认

我现在更倾向于把排查拆成三个问题：路径是不是符号链接、默认调用读的是谁、业务真正需要谁。这样能快速区分 API 语义问题和底层文件问题。

1. 先用 Files.isSymbolicLink(path) 判断路径类型，不要凭文件名后缀猜测。
2. 如果需要确认目标，可用 Files.readSymbolicLink(path) 查看链接保存的目标路径；这一步描述的是链接关系，不是目标属性。
3. 目标时间使用默认调用，链接时间使用 NOFOLLOW_LINKS，并把两次读取的变量命名为 targetTime、linkTime。
4. 遇到异常时记录操作对象和异常类型，但不要把“读取失败”解释成“时间为零”。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.LinkOption;
import java.nio.file.Path;

static void describe(Path path) {
    try {
        // 先确认路径类型，再选择与业务目标一致的属性读取策略。
        boolean symbolicLink = Files.isSymbolicLink(path);
        var targetTime = Files.getLastModifiedTime(path);
        var linkTime = symbolicLink
                ? Files.getLastModifiedTime(path, LinkOption.NOFOLLOW_LINKS)
                : targetTime;
        System.out.println("symbolicLink=" + symbolicLink);
        System.out.println("targetTime=" + targetTime);
        System.out.println("linkTime=" + linkTime);
    } catch (IOException ex) {
        // 路径失效、权限不足或文件系统能力不足都应保留为真实 I/O 错误。
        System.err.println("读取文件时间失败：" + ex.getMessage());
    }
}

失效链接、权限和文件系统边界

读取链接自身并不意味着所有环境都能无条件返回时间。路径不存在、链接目标失效、权限不足、路径类型不符合预期，都可能导致 I/O 异常。底层文件系统提供者对属性视图的支持也会影响结果，因此不要把某个平台上的精度或时间显示格式当成跨平台契约。

另一个容易混淆的点是“读取链接自身”和“读取链接目标”并不等于“修改链接自身”。如果要更新时间，需要另看 setLastModifiedTime 的行为和文件系统支持，不能因为读取时用了 NOFOLLOW_LINKS，就推断后续写入也会自动作用于链接目录项。

把语义固化进代码，避免下一次复盘

最后可以把策略命名成两个小方法：readTargetTime 只负责目标对象，readLinkTime 只负责链接自身。对外接口返回 FileTime，由上层决定展示、排序还是比较。这样做的收益不在于少写一个参数，而在于让“比较哪个对象”成为代码的一部分。

常见问题

不传 NOFOLLOW_LINKS 一定会读取目标文件吗？

对符号链接路径，默认规则是跟随链接读取目标对象；对普通文件路径则没有链接层可跟随。需要审计链接自身时，应显式传入 NOFOLLOW_LINKS。

FileTime 可以直接当作 Unix 时间戳吗？

不建议直接把对象当作数字使用。根据业务需要调用 toMillis() 或使用 compareTo，并明确精度和时区只是展示问题，不要混淆成文件属性语义。

符号链接失效时，NOFOLLOW_LINKS 能避免异常吗？

它能避免继续跟随链接，但不保证所有文件系统都能为失效链接提供可读的时间属性。调用仍应处理 IOException，并把“链接不存在”和“属性读取不支持”区分开。

为什么同步程序通常应该读目标时间？

如果同步目标是文件内容，目标对象的时间更贴近内容变化；如果同步目标是链接关系本身，则应额外读取链接自身。关键不是哪种写法更“正确”，而是调用语义要和同步对象一致。