Files.setLastModifiedTime() 调用无异常却未生效，主因是文件系统限制、权限不足、FileTime 构造不当或文件被独占占用；需检查可写性、用静态工厂方法构造FileTime，并用Files.getAttribute验证实际值。
Files.setLastModifiedTime() 是 Java NIO.2 提供的标准方式，能直接修改文件系统中文件的最后修改时间（lastModifiedTime），但实际使用时容易因权限、路径、属性类型或文件系统限制而失败——不是调用成功就真改了。
为什么 setLastModifiedTime() 调用没报错却没生效？
常见原因不是代码写错，而是底层约束未满足：
- 目标文件必须存在且可写（
Files.isWritable(path)应返回true）； - 传入的
FileTime不能为null，且推荐用FileTime.from(Instant)构造，避免毫秒精度丢失； - 某些文件系统（如 FAT32、部分网络挂载盘、macOS 的 APFS 加密卷）不支持纳秒级时间戳，会自动向下取整到秒甚至 2 秒，导致看似“没变”；
- Windows 下若文件被其他进程以独占方式打开（如记事本未关闭、IDE 正在索引），修改会静默失败（抛
IOException，但有时被忽略）。
正确构造并传入 FileTime 的三种常用方式
别直接 new FileTime，它没有 public 构造器。必须通过静态工厂方法：
- 设为当前时间：
FileTime.from(Instant.now())； - 设为指定毫秒时间戳（如从数据库读出的 long 值）：
FileTime.fromMillis(timestamp)； - 设为某个
ZonedDateTime对应的时间：FileTime.from(zdt.toInstant())。
注意：fromMillis() 会丢弃毫秒以下精度，适合兼容老系统；from(Instant) 保留纳秒（实际能否写入取决于文件系统）。
完整可运行示例与关键防御逻辑
下面这段代码做了三件事：检查可写性、捕获具体异常、验证结果是否真正更新：
Path path = Paths.get("/tmp/test.txt");
if (!Files.exists(path)) {
Files.createFile(path);
}
// 必须先确保可写
Files.setAttribute(path, "dos:readonly", false, LinkOption.NOFOLLOW_LINKS); // Windows
Files.setPosixFilePermissions(path, PosixFilePermissions.fromString("rw-r--r--")); // Unix
FileTime newTime = FileTime.from(Instant.parse("2024-01-01T00:00:00Z"));
try {
Files.setLastModifiedTime(path, newTime);
FileTime actual = (FileTime) Files.getAttribute(path, "basic:lastModifiedTime");
System.out.println("设置后时间：" + actual); // 看是否真变了
} catch (IOException e) {
System.err.println("修改失败：" + e.getMessage()); // 比如 "Access is denied" 或 "Operation not supported"
}
特别提醒：Files.getAttribute(..., "basic:lastModifiedTime") 返回的就是当前实际值，务必用它验证，不要只信 try 块没抛异常。
最容易被忽略的是：不同操作系统对时间戳的最小单位支持不同，Windows NTFS 支持 100 纳秒，Linux ext4 默认支持纳秒但 mount 参数可能禁用，而很多 Docker 容器挂载的 host 目录走的是 VirtualBox 共享文件夹（仅支持秒级）。改完发现时间只精确到秒？先查挂载方式，再查 stat -c "%y" file 看底层真实精度。
