files.move()跨文件系统操作天然非原子，因需复制+删除两阶段；应通过filestore比对判断是否同文件系统，并采用复制校验→原子重命名→删除源的三步容错流程。

Files.move() 在跨文件系统操作时完全不能保证原子性，这是由操作系统底层限制决定的，Java 无法绕过。

为什么跨文件系统移动天然是非原子的

原子重命名依赖的是文件系统的 rename(2) 系统调用（Linux/macOS）或类似机制（Windows 同卷），它只在同一文件系统内有效。跨文件系统（例如从 /home 移到 /mnt/usb，或 Windows 的 C: → D:）时：

• 操作系统必须实际读取源文件内容、写入目标位置——这是耗时、可中断的 I/O 过程
• Files.move() 会自动退化为“复制 + 删除”两阶段操作
• 若在复制中途崩溃、断电或磁盘满，可能出现：源文件已被删除，而目标文件不完整或根本不存在
• ATOMIC_MOVE 选项在这种情况下被静默忽略，不会报错也不会警告

如何判断是否跨文件系统

不能靠路径字符串猜测，必须通过文件系统对象比对：

• 用 Files.getFileStore(path) 获取源和目标父目录的 FileStore
• 比较两者是否相等：Files.getFileStore(source).equals(Files.getFileStore(target.getParent()))
• 更轻量方式（仅限同主机本地路径）：source.toRealPath().getRoot().equals(target.toRealPath().getRoot())

跨文件系统时的安全替代方案

放弃“一步原子”，改用可控的三步容错流程：

• 先用 Files.copy(source, tempTarget, REPLACE_EXISTING) 复制到目标卷上的临时路径（如 target.tmp）
• 校验复制结果：至少检查 Files.size(tempTarget) == Files.size(source)；高要求场景加哈希比对
• 校验通过后，再执行 Files.move(tempTarget, target, REPLACE_EXISTING) ——这一步在同一卷内是原子的
• 最后才调 Files.delete(source)；若失败，保留源文件，人工介入清理

REPLACE_EXISTING 和 ATOMIC_MOVE 不是默认行为

这两个选项都必须显式传入，否则行为与直觉相反：

• 不加 REPLACE_EXISTING，目标已存在时直接抛 FileAlreadyExistsException
• 不加 ATOMIC_MOVE，即使同文件系统，也不承诺原子性（只是大概率快且安全）
• 同时使用两者，才能在同卷下实现“覆盖式原子移动”

本质上，原子性不是 Java API 赋予的能力，而是你主动确认环境、选择合适路径、并分层控制每一步的结果。