File.setLastModified 返回 false 主因是底层限制：文件不存在、无写权限、文件系统禁用时间戳更新、Windows 链接异常或文件被独占占用；需确保 exists()、isFile()、canWrite() 均为 true 且时间值合法。

Java 中 File.setLastModified 为什么经常返回 false？

直接调用 file.setLastModified(System.currentTimeMillis()) 却返回 false，大概率不是代码写错了，而是底层限制在起作用。这个方法返回 false 表示“操作未成功”，常见原因包括：
- 文件不存在（file.exists() 为 false）
- 当前进程没有该文件的写权限（Linux/macOS 下尤其明显）
- 文件系统挂载时禁用了时间戳更新（比如某些 NFS 或只读挂载）
- Windows 上对 NTFS 硬链接或符号链接调用时行为不确定
- 文件正被其他进程以独占方式打开（如记事本、IDE 正在编辑中）

正确调用 File.setLastModified 的前提条件

必须确保以下几点同时满足，否则返回 false 是预期行为，不是 bug：
- file.isFile() 返回 true（不能是目录）
- file.canWrite() 返回 true（有写权限）
- file.exists() 返回 true（路径真实存在）
- 时间戳值需为非负 long（毫秒级，1970-01-01 后），且不能超过系统支持上限（通常没问题）
- 避免在多线程环境下对同一文件频繁并发调用（不保证原子性，但一般不影响单次结果）

替代方案：当 File.setLastModified 失败时怎么办？

如果确认权限和路径无误但仍失败，说明 JVM 底层调用 utimes()（Unix）或 SetFileTime()（Windows）被拒，可考虑：
- 改用 java.nio.file.Files.setLastModifiedTime：更现代、抛出明确异常（如 IOException 或 SecurityException），便于诊断
- 示例：

Path path = Paths.get("example.txt");<br>Files.setLastModifiedTime(path, FileTime.fromMillis(System.currentTimeMillis()));

- 某些场景下，用空内容追加写入（Files.write(path, new byte[0], StandardOpenOption.APPEND)）也能触发时间戳更新，但会改变文件大小，慎用
- Linux 下可临时用 Runtime.getRuntime().exec("touch -d @1234567890 example.txt") 委托 shell，但依赖外部命令且跨平台差

注意时区与精度陷阱

File.setLastModified 接收的是自 epoch 起的毫秒数，它本身不涉及时区——但你构造这个值的方式可能引入偏差：
- 不要用 SimpleDateFormat 解析带时区的字符串再转毫秒，容易错算
- System.currentTimeMillis() 是本地系统时钟，若系统时间不准，设出来的“最后修改时间”就不可信
- FAT32 文件系统只保留 2 秒精度，NTFS 和 ext4 通常是 100ns 级，但 File API 最高只到毫秒，所以别指望设出微秒级差异
- 多次快速连续调用（比如循环里设不同时间）可能因系统时钟粒度或文件系统缓存，导致实际写入的时间戳相同