File.Move失败主因是路径不合法：源和目标必须为完整文件路径，目标目录须预先存在；不支持跨卷原子移动、同名覆盖及批量操作，网络/符号链接等特殊路径需额外验证。
MoveFile 会失败？先确认 File.Move 的路径约束
File.Move 不是“剪切粘贴”的图形化操作，它底层依赖操作系统对文件句柄和目录结构的控制。最常见失败不是权限问题，而是路径不合法：sourceFileName 和 destFileName 必须是完整路径（含扩展名），且目标路径不能只写到目录层级——比如 "C:\target" 会抛 System.IO.IOException: The directory is not empty 或直接报“找不到路径”，因为 File.Move 要求目标参数是**新文件全路径**，不是目标文件夹。
- ✅ 正确：
File.Move("C:\a\log.txt", "C:\b\archive_log.txt") - ❌ 错误：
File.Move("C:\a\log.txt", "C:\b\")（目标不是文件路径） - ⚠️ 注意：目标目录必须已存在；
File.Move不自动创建父目录 - ⚠️ 跨卷移动（如 C: → D:）在 Windows 下实际是“复制+删除”，失败时源文件可能已删但目标未写完，不可靠
想覆盖同名文件？File.Move 不支持，得手动处理
File.Move 遇到目标路径已存在时，会直接抛 System.IO.IOException: Cannot create a file when that file already exists。它没有 overwrite 参数——这是和 File.Copy 最关键的区别之一。
- 若需覆盖：先用
File.Exists(dest)判断，再调用File.Delete(dest)，最后File.Move - 但要注意：两次 I/O 操作之间存在竞态窗口（其他进程可能新建同名文件），生产环境建议用
try/catch包裹整个流程并重试 - 更稳妥的做法是改用
File.Replace（.NET 4.0+），它原子性地用新文件替换旧文件，并可选保留旧版本备份：File.Replace("new.dat", "old.dat", "old.bak")
移动大量小文件时卡顿？别用 File.Move 逐个调用
每个 File.Move 都是一次独立的 Win32 API 调用（MoveFileEx），在循环中移动数百个文件时，I/O 调度开销明显。尤其当源/目标在同一磁盘时，本质是元数据更新，但 .NET 层无批量接口。
- 优化方向：用
Process.Start("cmd", "/c move ...")委托给 shell（不推荐，难捕获错误） - 更可靠方案：改用
Directory.GetFiles+Parallel.ForEach控制并发数（如MaxDegreeOfParallelism = 4），避免线程爆炸 - 极端场景（TB 级日志归档）：考虑调用 Windows API
CopyFileEx配合MOVEFILE_WRITE_THROUGH标志，但需 P/Invoke，复杂度陡增
网络路径、OneDrive、符号链接下移动文件要格外小心
File.Move 对 UNC 路径（\servershare ile.txt）基本可用，但一旦涉及同步服务（OneDrive、Google Drive）、DFS、或 NTFS 符号链接，行为就变得不可预测。
- OneDrive 中的文件：移动后可能触发“按需文件”状态错乱，甚至丢失本地句柄，建议先
File.Copy再File.Delete - 符号链接：默认移动的是链接本身，不是目标文件；加
FileOptions.OpenReparsePoint可操作链接目标，但需额外判断类型 - 权限提示：网络路径失败时，异常里常带
UnauthorizedAccessException，但真实原因是 SMB 共享级权限不足，而非本地 ACL —— 检查共享权限和 NTFS 权限是否都放行了“修改”
真正麻烦的从来不是语法，而是你不知道目标路径背后挂的是什么——可能是 WSL2 的 ext4 卷、Azure 文件存储的 REST 接口模拟层，或者管理员刚启用了文件屏蔽策略。动手前，先 File.GetAttributes 看一眼 FileAttributes.ReparsePoint 和 FileAttributes.Offline。
