Files.getLastModifiedTime() 返回 FileTime 类型，底层为纳秒精度的纪元时间；可调用 toInstant()、toMillis() 等方法转换，但不可直接强转或调用不存在的 getTime() 方法。
Files.getLastModifiedTime() 返回的是什么时间类型
Files.getLastModifiedTime() 返回的是 FileTime 类型，不是 long 毫秒值，也不是 Instant 或 LocalDateTime。直接打印会看到类似 2024-05-12T08:23:41.123Z 的字符串，但这是 FileTime.toString() 的格式化结果，底层是纳秒精度的纪元时间（epoch nanos）。
常见错误是试图用 fileTime.getTime()（这个方法根本不存在）或强制转型为 Date——FileTime 和 Date 无继承关系，必须显式转换：
- 转
Instant：调用fileTime.toInstant() - 转毫秒值：用
fileTime.toMillis()（注意：会截断纳秒，且对某些文件系统可能返回 -1，表示不支持或不可用） - 转
ZonedDateTime：先toInstant()，再.atZone(ZoneId.systemDefault())
为什么有时拿到的时间是 1970-01-01 或抛 UnsupportedOperationException
两种典型现象：FileTime.from(0)（即 1970-01-01T00:00Z）或抛出 UnsupportedOperationException，基本都指向同一个原因：目标文件不支持最后修改时间属性，或者 Java 无法从底层文件系统读取该元数据。
常见场景包括：
- 文件位于只读挂载点（如某些 Docker volume、NFS 共享、FAT32 分区）
- 使用了不支持时间戳的虚拟文件系统（如
MemoryFileSystem、某些测试 mock） - Java 运行在受限容器中，且宿主机文件系统权限/挂载选项屏蔽了
st_mtime - 路径指向的是符号链接，而你没设置
LinkOption.NOFOLLOW_LINKS，导致解析失败
安全做法是始终捕获 IOException 并检查返回值是否为 FileTime.from(0)（虽然不能 100% 代表无效，但结合异常更可靠）。
检查文件是否“刚被修改”时别直接比 long 毫秒
想判断一个文件是不是最近 5 秒内被改过？别写 Math.abs(System.currentTimeMillis() - fileTime.toMillis()) 。问题在于：<code>toMillis() 会丢掉纳秒部分，且不同系统对“最后修改时间”的刷新粒度不同（例如 FAT32 是 2 秒，ext4 默认是纳秒但可能受挂载参数影响）。
更稳妥的方式是用 Instant 做比较：
try {
FileTime lastMod = Files.getLastModifiedTime(path);
Instant now = Instant.now();
Instant modTime = lastMod.toInstant();
if (Duration.between(modTime, now).getSeconds() <= 5) {
// 确认是最近 5 秒内
}
} catch (IOException e) {
// 处理无法读取的情况
}这样既保留精度，又避免手动算毫秒差带来的溢出或时区混淆风险。
Windows 上要注意文件重命名和复制行为的影响
在 Windows 中，单纯重命名一个文件（Files.move(src, dst, StandardCopyOption.REPLACE_EXISTING)）通常不会改变 lastModifiedTime；但用资源管理器拖拽复制，或通过 Files.copy() 创建新文件，则新文件的 lastModifiedTime 默认继承源文件——除非你显式调用 Files.setAttribute(..., "basic:lastModifiedTime", ...) 覆盖。
所以如果你依赖这个时间做“文件新鲜度”判断，要清楚：它反映的是内容最后一次写入磁盘的时间，不是文件被移动/重命名的时间，更不是程序调用 write() 的时刻（中间有缓冲）。真正关键的边界情况，往往藏在文件系统语义和 Java 封装之间的那层薄薄的抽象之下。
