File.Replace 不幂等因其仅做路径级原子替换，不校验内容；需自行添加哈希比对（如 SHA256）+ File.Exists 判断，确保“内容一致则跳过”，才满足幂等性要求。
用 File.Replace 替换文件时为什么还是不幂等？
因为 File.Replace 本身不检查源文件内容是否变化，只做路径级原子替换。如果两次调用传入相同目标路径但不同源文件，它会无条件覆盖——这违反幂等性核心：「相同输入 → 相同结果」。
真正要的是「若目标已存在且内容一致，就跳过写入」。得自己加校验层。
- 先用
File.GetLastWriteTimeUtc或File.GetAttributes快速判断目标是否存在且非空，能筛掉大部分重复场景 - 必须比对内容哈希（如
SHA256）而非仅文件大小或时间戳——Windows 文件系统时间精度低，且用户可能手动改过时间 -
File.Replace的第三个参数ignoreMetadataErrors设为true可避免因只读/隐藏属性导致失败，但这不解决幂等逻辑问题
写入前用 File.Exists + ComputeHash 判断是否跳过
这是最可控的幂等入口。关键不是“有没有文件”，而是“内容是否已满足要求”。直接读全量文件算哈希成本高，但对中小文件（
示例逻辑：
var targetPath = "config.json";
var sourceBytes = File.ReadAllBytes("config.template.json");
var targetHash = File.Exists(targetPath)
? ComputeHash(targetPath)
: null;
var sourceHash = ComputeHash(sourceBytes);
if (!targetHash?.SequenceEqual(sourceHash) == true)
{
File.WriteAllBytes(targetPath, sourceBytes);
}
-
ComputeHash要用using var sha = SHA256.Create()，别复用静态实例（线程不安全） - 不要用
File.ReadAllText+Encoding.UTF8.GetBytes算哈希——BOM、换行符、编码隐式转换会让哈希失效 - 若目标文件正被其他进程打开（如日志文件），
File.OpenRead会抛IOException，需捕获并降级为跳过或重试
用 FileStream 配合 FileShare.Read 安全读取待比较文件
很多线上环境目标文件被另一服务独占打开（比如 IIS 托管的 Web.config），此时直接 File.OpenRead 必然失败。必须显式声明共享模式。
正确做法是绕过 File.* 静态方法，用底层流控制：
using var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read);
-
FileShare.Read允许其他进程同时读，但不能写；若对方以FileShare.None打开（极少见），仍会失败 - 别用
FileShare.ReadWrite——可能读到正在写入的脏数据，哈希比对失真 - 大文件建议分块哈希（
sha.TransformBlock），避免一次性加载进内存，但要注意最后一块TransformFinalBlock调用时机
临时文件 + 原子重命名为什么还不够？
用 Path.GetTempFileName() 写新内容，再 File.Move 替换目标，看似原子，实则漏掉关键点：如果两次生成的临时文件内容相同，但目标文件已被外部修改，这次「Move」仍是覆盖行为，不是条件跳过。
也就是说，原子性 ≠ 幂等性。前者保证操作不中断，后者保证逻辑不冗余。
-
File.Move在 NTFS 上是元数据操作，快且原子，但无法替代内容校验 - 临时文件路径要用
Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString())，避免GetTempFileName的 65535 限制和潜在竞争 - 若目标在另一磁盘分区，
File.Move实际是复制+删除，失去原子性——此时必须用File.Replace或自行实现跨卷安全替换
真正难的不是“怎么换文件”，而是“怎么确认没必要换”。校验逻辑一旦写错，幂等就变成掩耳盗铃。尤其要注意多线程并发写同一路径时，两个线程同时通过哈希校验、又同时写入——得靠 lock 或 ConcurrentDictionary 键级锁兜底，这点常被忽略。
