Java Files.readAttributes 怎么判断配置文件是否被替换：BasicFileAttributes、fileKey 与时间戳陷阱

配置文件热加载最容易误判的地方，不是“有没有变化”，而是“这个路径指向的还是不是同一个文件”。如果发布脚本先写临时文件，再用重命名替换 config.yml，只比较 lastModifiedTime 可能漏掉文件身份变化；反过来，文件系统时间精度不足时，连续两次覆盖也可能看起来没变。

先把一次文件检查收敛成快照

只关心最后修改时间时，Files.getLastModifiedTime(path) 就够了；需要同时看文件身份、大小和类型时，用 Files.readAttributes 更合适。Oracle 的 NIO 文档把这些属性定义为同一组基本文件属性，读取后可以在应用侧保存。

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.attribute.BasicFileAttributes;

static BasicFileAttributes snapshot(Path path) throws IOException {
    return Files.readAttributes(path, BasicFileAttributes.class);
}

static boolean changed(BasicFileAttributes oldAttrs,
                       BasicFileAttributes newAttrs) {
    return !java.util.Objects.equals(oldAttrs.fileKey(), newAttrs.fileKey())
        || oldAttrs.size() != newAttrs.size()
        || !oldAttrs.lastModifiedTime().equals(newAttrs.lastModifiedTime());
}

这里的顺序有一个实际好处：fileKey 先判断路径是否换了对象，大小和修改时间再补充内容变化的线索。快照只描述元数据，不代表已经读到了一个完整、可解析的配置版本。

为什么 fileKey 能抓住“临时文件替换”

常见发布动作是写入 config.yml.tmp，关闭文件后再把它替换到目标路径。路径字符串没有变，但路径背后的文件对象可能已经换了。此时，新的 fileKey() 若可用，通常会与旧快照不同，程序可以把它当成“重新打开并完整读取”的信号。

但不能把 fileKey 当成跨平台绝对保证。官方接口明确允许文件系统在不支持文件键时返回 null，而且它的唯一性保证依赖文件系统和文件保持静态。因此比较时必须用 Objects.equals，不要直接调用 oldKey.equals(newKey)。

Object oldKey = oldAttrs.fileKey();
Object newKey = newAttrs.fileKey();

boolean identityChanged = !java.util.Objects.equals(oldKey, newKey);
if (identityChanged || oldAttrs.size() != newAttrs.size()) {
    // 重新读取并解析完整配置，避免只拿到半截内容
}

时间戳为什么不能单独当作版本号

lastModifiedTime() 是文件系统提供的时间属性，不是应用层递增版本号。不同文件系统的时间精度和支持程度不同；官方文档也说明，不支持某类时间戳时可能返回实现相关的默认值。连续快速写入、手工恢复旧文件时间，都会让“时间相同”或“时间变早”出现。

图片中的两个分支对应两种很容易混在一起的情况：原地覆盖可能保持同一个文件身份但改变大小或时间；临时文件替换可能先改变文件身份。实际代码应把这些属性作为触发读取的联合条件，而不是拿某一个字段作绝对结论。

读到变化后，如何避免加载半截配置

元数据发生变化只说明“值得重新读取”，不说明当前内容已经稳定。推荐把读取、解析和替换内存对象放在一次可回滚的流程里：

1. 重新读取快照，确认路径仍是普通文件。
2. 把文件完整读入临时字符串或字节数组，再解析。
3. 解析成功后一次性替换内存中的配置对象；失败时保留旧对象并记录路径、大小和异常。
4. 解析结束后再次读取快照。如果前后快照仍不一致，丢弃本次结果，等待下一轮。

最后一步是为了挡住“读取期间又被发布脚本替换”的窗口。它不是严格事务，但比只在入口处读一次属性更容易发现竞态。

常见问题

fileKey 为 null 时还能判断文件被替换吗？

可以把大小、修改时间和两次完整读取后的内容摘要结合起来，但要承认这是降级判断，不能宣称拥有文件身份级别的证据。

只判断 size 变化够不够？

不够。不同内容可能拥有相同大小；大小更适合作为低成本的变化线索，不能替代内容校验或文件身份判断。

什么时候直接使用 WatchService？

需要低延迟接收目录事件时可以使用它，但事件仍应触发元数据快照和稳定性复查。事件本身不是完整文件版本。

小结

Files.readAttributes 的价值在于把文件身份、大小和时间属性放到同一份快照里。对配置热加载来说，fileKey 能补上“路径没变、文件已替换”的判断缺口；当它不可用时，就用多字段变化和二次快照复查降低误判，再把解析成功作为真正的切换条件。