应采用原子重命名（写入临时文件后Move）或在文件内容中嵌入时间戳，而非依赖File.SetLastWriteTime；必须显式调用Flush(true)确保落盘，禁用LastAccessTime以减少干扰。

崩溃时 File.SetLastWriteTime 和文件内容不同步怎么办

Windows 下 C# 写文件后调用 File.SetLastWriteTime，若进程在写入中途崩溃，极大概率出现「文件内容是旧的，但时间戳却是新的」——元数据和数据体脱节。这不是 .NET 的 bug，而是 NTFS 缓存策略 + 用户态 API 语义不保证原子性的结果。

实操上别指望单次 SetLastWriteTime 能兜底。真正可靠的做法是：把时间戳作为数据的一部分写入文件，或用原子重命名配合临时文件。

• 写入时先写到 data.tmp，再写入完整内容，再调用 File.SetLastWriteTime，最后 File.Move 覆盖原文件（NTFS 上 Move 到同卷是原子的）
• 避免在 FileStream 关闭前调用任何元数据修改 API；务必用 using 或 try/finally 确保 Flush() 和 Close() 执行完毕
• 如果必须改时间戳且不能重命名（比如日志轮转场景），至少加一层校验：读取文件哈希或长度，匹配成功后再更新时间戳

FileStream 没 Flush(true) 就崩溃，元数据肯定丢

FileStream.Flush(true) 是强制刷盘的关键开关，不带 true 只清托管缓冲区，底层 OS 缓存仍可能滞留数据和时间戳。很多开发者以为 Dispose() 会自动全量落盘，其实 Windows 默认策略下不会。

尤其在 SSD 或启用了写缓存的磁盘上，Flush(false) 后立刻断电，连文件大小都可能回滚到上次真正刷盘的状态。

• 写关键文件时，显式调用 fs.Flush(true)，不要依赖 Dispose() 的隐式行为
• 注意 Flush(true) 是同步阻塞调用，性能敏感路径需权衡；可考虑批量写+定期 Flush(true)，但崩溃容忍度下降
• 检查磁盘是否禁用写缓存：fsisk /query（命令行）或 WMI 查询 Win32_Volume 的 DisableLastAccessUpdate 属性——它会影响时间戳更新时机

用 TransactedFile？别试了，Windows 已弃用

.NET 没有内置事务化文件 API，而 Windows 原生的 Transactional NTFS（TxF）早在 Windows 8 / Server 2012 就被标记为 deprecated，.NET 也从未封装过 CreateTransaction 等底层函数。试图用 Kernel32.CreateTransaction 手动调用不仅复杂，还会在多数现代系统上直接失败。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

真实项目里硬上 TxF 的代价远高于收益：驱动兼容性差、杀毒软件拦截率高、日志体积暴增，且无法跨卷事务。

• 替代方案只有两种：基于重命名的原子提交（推荐），或用 SQLite 等嵌入式 DB 存储结构化元数据（适合多字段强一致性场景）
• 若业务逻辑要求「文件存在即代表元数据有效」，就在文件头预留 16 字节签名区，写入时先填占位符，写完再覆写校验值——比依赖外部时间戳更可控

崩溃后靠 File.GetLastWriteTime 判断文件是否完整？危险

File.GetLastWriteTime 返回的是最后一次内核标记的时间，不是数据实际落盘时间。崩溃后这个值可能比内容新，也可能比内容旧（例如写入中途被抢占，时间戳已更新但内容只写了一半）。

它唯一能说明的，只是「某个线程曾经调用过 SetLastWriteTime」，完全不能反映文件数据完整性。

• 校验文件是否可用，必须结合内容：计算 CRC32 或读取固定头部 Magic Number
• 日志类文件可加写入序列号（如每行开头 [seq:123]），崩溃恢复时扫描最大连续序号
• 不要在 catch 块里仅凭时间戳做清理决策——你删掉的可能是「刚写一半但时间戳已更新」的脏文件

最常被忽略的一点：NTFS 卷默认启用 LastAccessTime 更新，它会额外触发磁盘 I/O，干扰你对 LastWriteTime 的观察。生产环境应通过 fsutil behavior set disablelastaccess 1 关闭它，否则时间戳本身就成了不可靠变量。