File.Move 比 File.Copy + File.Delete 更安全，因其调用系统级 rename 实现原子操作、不占额外空间、无残留风险；同一卷内瞬时完成，跨卷时内置回滚；目标存在时明确抛异常而非覆盖；需用全路径并校验合法性。
File.Move 为什么比 File.Copy + File.Delete 更安全
重命名文件本质是移动操作，不是覆盖或新建。C# 中 File.Move 直接调用系统级 rename，原子性强、不占用额外磁盘空间、不会因中断留下残留文件。
- 用
File.Copy+File.Delete组合，一旦复制完成但删除失败（比如目标被占用），就会出现“原文件还在、新文件也存在”的重复状态 -
File.Move在同一卷内是瞬间完成的；跨卷则自动退化为复制+删除，此时它内部已做了异常回滚处理——这点很多人不知道，误以为它跨盘会出问题 - 如果目标路径已存在，
File.Move会直接抛出IOException，不会静默覆盖，符合预期安全性
路径参数必须是完整路径，相对路径容易踩空
File.Move 不做路径解析，传入什么就当什么用。当前工作目录（Environment.CurrentDirectory）对它完全无效。
- 错误写法：
File.Move("old.txt", "new.txt")—— 这会在进程启动目录下找old.txt，极大概率抛出FileNotFoundException - 正确做法：所有路径都用
Path.GetFullPath或拼全路径，例如File.Move(@"C:\data\old.txt", @"C:\data\new.txt") - 若来源路径来自用户输入或配置，务必先用
File.Exists检查，否则异常信息里只报“找不到路径”，不提示是源还是目标的问题
中文名、特殊字符、长路径需要额外开关
默认 .NET 运行时对长路径（>260 字符）和某些 Unicode 文件名支持有限，尤其在旧版 Windows 上。
- Windows 10 1607+ 需开启组策略或应用清单启用长路径支持，否则
File.Move遇到超长路径直接抛PathTooLongException - 中文路径本身没问题，但若路径含
:、、<code>>、|等非法字符，会在调用前就触发ArgumentException，不是系统级错误 - 建议封装一层校验：用
Path.GetInvalidFileNameChars()和Path.GetInvalidPathChars()提前过滤，比等异常更可控
异步重命名？别用 File.MoveAsync 做假并发
File.MoveAsync 并非真正异步 I/O，它只是把 File.Move 包进线程池执行，底层仍是同步系统调用。
- 高并发重命名场景（如批量日志归档），大量
File.MoveAsync可能挤占线程池资源，反而拖慢主线程响应 - 真要降阻塞，应控制并发数（比如用
SemaphoreSlim限流），而不是盲目加async/await - 若目标路径在远程 SMB 共享上，
File.Move会明显变慢且易超时，这时要考虑是否真该在 IO 层做重命名，还是交由服务端脚本处理
最常被忽略的是权限检查时机——File.Move 要求对源目录有读+删权限，对目标目录有写+创建权限。这两个权限可能分属不同用户组，运行时才暴露，没法静态预判。
