windows上file.move同卷操作是原子的，因调用movefileex+movefile_replace_existing，仅更新元数据；跨卷则退化为复制+删除，非原子。
Windows 上 File.Move 为什么常被当作原子操作用
在 Windows（NTFS）上，File.Move 对**同一卷内**的重命名（rename）操作，底层调用的是 MoveFileEx 并传入 MOVEFILE_REPLACE_EXISTING 标志，它最终由文件系统驱动通过原子化的元数据更新完成——不涉及数据块拷贝，只改目录项和 MFT 记录。所以只要源路径和目标路径在同一磁盘卷，这个操作就是原子的：要么全部成功（文件出现在新位置、旧位置消失），要么完全失败（原文件完好无损），不会出现“一半在旧路径、一半在新路径”的中间态。
- 仅限同卷：跨卷移动（比如 C: → D:）会退化为“复制 + 删除”，显然非原子
- 不保证内容可见性：原子 ≠ 即时同步到所有 CPU 缓存；若其他进程正用
FileStream持有该文件句柄，Move仍可能成功，但对方读写行为未定义 - 权限与锁影响结果：目标路径被占用、权限不足、或文件正被独占打开，都会抛出
IOException，不是“部分成功”
File.Replace 是更安全的原子替换方案
当你需要“用新文件安全覆盖旧文件”（比如更新配置、升级资源），直接 File.delete + File.copy 有明显窗口期：删完还没写入时崩溃，旧文件就丢了。File.Replace 则利用 NTFS 的“事务性重命名”能力，把旧文件先备份（可选），再原子地把新文件“切换”成目标名，整个过程不可中断。
- 签名是
File.Replace(String sourceFileName, string destinationFileName, string? backupFileName) - 如果
backupFileName不为NULL，旧文件会被移到备份路径；否则直接丢弃 - 注意：备份路径必须与目标路径同卷，否则抛
ArgumentException - linux/macos 不支持此 API（.NET 6+ 在这些平台会回退为非原子的拷贝+删除）
别信“File.Move 总是原子”——常见翻车点
很多开发者看到文档里写“atomic on same volume”就默认高枕无忧，结果在线上出问题。根本原因在于：原子性只承诺**文件系统层面的路径变更**，不兜底你的业务语义。
- 目标路径存在且是目录？抛
UnauthorizedAccessException，不是静默失败 - 路径含非法字符（如
*、?）或超长（>260 字符且未启用长路径支持），提前在托管层报错，根本没进系统调用 - 使用 UNC 路径（
servershare）时，实际行为取决于远程服务器的文件系统和 SMB 版本，Windows Server 2012+ 的 SMB 3.0 才较可靠支持原子重命名 -
File.Move不刷新其他进程的目录缓存；某线程刚列完目录又执行 Move，下次再列可能还看到旧名（需手动Directory.Refresh()或加重试）
跨平台原子重命名？没有银弹，只有取舍
.NET 本身不提供跨平台原子 rename，因为 Linux（ext4/xfs）和 macOS（APFS）虽支持 rename(2) 系统调用（同挂载点下是原子的），但 .NET 的 File.Move 在非 Windows 上只是封装了该调用，并不额外保证更高层语义。
- 同挂载点：Linux/macOS 的
File.Move和 Windows 一样，是原子的 - 不同挂载点（哪怕都是本地磁盘）：必然跨设备，
rename(2)失败，.NET 回退为 copy+delete，非原子 - 容器/网络存储场景更复杂：OverlayFS、NFSv3、S3 兼容网关等，
rename可能被模拟实现，原子性彻底失效 - 真正要跨平台强保障？只能自己加锁（如
FileSystemWatcher+ 临时文件 + 原子写入标志位）或依赖数据库事务记录状态
事情说清了就结束。原子性永远绑定在具体环境和操作粒度上，文件系统说原子，不等于你的业务逻辑自动变安全。