Files.move无法跨文件系统原子移动，因底层rename(2)系统调用仅支持同文件系统，跨挂载点时返回EXDEV错误，JDK回退为非原子的copy+delete，中间状态可见且易致数据不一致。
Java 的 Files.move 无法在跨文件系统时实现真正的原子移动操作。
为什么跨文件系统不能原子移动
原子移动（atomic move）依赖底层操作系统提供的“重命名”语义，而该语义仅在同一文件系统内有效。当源路径和目标路径位于不同挂载点（如 /home 和 /tmp，或不同磁盘、网络文件系统）时，Linux/Unix 的 rename(2) 系统调用会失败并返回 EXDEV 错误。Java 的 Files.move 在遇到此错误时会自动退化为“复制 + 删除”逻辑，这个过程不是原子的：中间状态（文件已复制但未删除原文件）可见，且可能因中断、异常或权限问题导致数据不一致。
Files.move 的实际行为（跨文件系统）
当你调用：
Files.move(source, target, StandardCopyOption.REPLACE_EXISTING);
立即学习“Java免费学习笔记（深入）”；
若跨文件系统，JDK 内部会：
- 尝试调用 native
rename—— 失败（EXDEV） - 回退为：先
Files.copy源到目标，再Files.delete源 - 整个过程无事务保障；复制中途失败会导致目标残留部分文件、源仍存在
- 即使加了
ATOMIC_MOVE选项（Java 11+），跨文件系统时也会直接抛出FileSystemException，不会静默降级
替代方案：如何安全处理跨文件系统“移动”
若业务逻辑要求“移动语义”，需自行实现容错与清理逻辑：
-
先复制后校验再删除：用
Files.copy(..., REPLACE_EXISTING)→ 校验大小/哈希 → 成功后再Files.delete(source) -
使用临时目标 + 原子重命名（同文件系统内）：将目标路径设为与源同文件系统的临时位置（如
/var/tmp），复制完成后，在目标文件系统内用原子 rename 放入最终路径（需提前确保目标目录可写） - 记录操作日志 + 补偿机制：写入操作前先持久化“待移动”元数据（如 DB 或日志文件），失败时根据日志恢复一致性
-
避免强求原子性，改用明确状态标识：例如重命名源为
xxx.moving，复制完成后重命名目标为xxx.done，应用层按状态决定是否启用
如何判断是否跨文件系统
可通过 FileStore 判断两个路径是否属于同一文件系统：
Path source = Paths.get("/mnt/disk1/data.txt");<br>Path target = Paths.get("/mnt/disk2/backup.txt");<br><br>FileStore srcStore = Files.getFileStore(source);<br>FileStore tgtStore = Files.getFileStore(target);<br>boolean sameStore = srcStore.equals(tgtStore); // 注意：equals 不保证跨 JVM 一致，建议配合 isSameFileStore（Java 11+）
Java 11 起推荐用：srcStore.isSameFileStore(tgtStore)，更可靠。
