file.delete仅执行逻辑删除，不擦除磁盘数据；真正防恢复需覆写文件内容三遍并强制落盘，但ssd上无效，应依赖trim或厂商安全擦除工具。
用 File.Delete 只是删了文件名，不是真正擦除数据
Windows 和大多数文件系统（NTFS、FAT32、exFAT）的「删除」本质是把文件在目录表里的记录标记为“可覆盖”，磁盘上原始字节块还完整躺着。只要没被新数据写入，用 Recuva、PhotoRec 甚至直接十六进制编辑器都能捞回来。File.Delete 完全不碰实际数据块，它只是操作系统层面的“逻辑删除”。
所以如果你真需要防恢复，必须主动覆写文件占用的磁盘扇区——而这在 .NET 标准库中没有开箱即用的 API。
手动覆写文件内容再删：最可控但要注意三遍写入和清缓存
核心思路是：打开文件、用随机字节或零反复写满整个长度、刷新到磁盘、再删除。关键点不在“写几次”，而在于确保写入真的落盘，且不被系统缓存干扰。
- 必须用
FileMode.Open+FileAccess.Write，不能用Create或Truncate，否则可能只改了文件头，没动原始数据块 - 写完每一轮后调用
stream.Flush(true)，第二个参数true强制绕过 OS 缓存直写磁盘（需要管理员权限或卷支持） - 推荐至少覆写三轮：
0x00→0xFF→ 随机字节，符合 DoD 5220.22-M 基础要求 - 最后再调用
File.Delete，此时文件已无有效数据，删除只是清理元信息
using var fs = new FileStream(path, FileMode.Open, FileAccess.Write, FileShare.None, 4096, FileOptions.WriteThrough); var buffer = new byte[fs.Length]; // 第一遍：全零 fs.Write(buffer, 0, buffer.Length); fs.Flush(true); // 第二遍：全 0xFF Array.Fill(buffer, (byte)0xFF); fs.Write(buffer, 0, buffer.Length); fs.Flush(true); // 第三遍：随机 using var rng = RandomNumberGenerator.Create(); rng.GetBytes(buffer); fs.Write(buffer, 0, buffer.Length); fs.Flush(true); File.Delete(path);
用 CryptographicOperations.ZeroMemory 没用，它只清内存
有人看到 CryptographicOperations.ZeroMemory 就以为能“安全清空文件”，这是典型误解。这个方法只作用于托管内存中的 Span<byte>，对磁盘上的文件数据零影响。它清的是你刚读进来的那几 KB 内存缓冲区，不是磁盘扇区。
-
CryptographicOperations.ZeroMemory不接受文件路径、流或句柄 - 即使你把整个文件读进内存再清，原始磁盘数据依然完好无损
- 大文件读入内存还会引发
OutOfMemoryException，纯属反模式
SSD 上覆写基本无效，得靠 TRIM 或厂商工具
固态硬盘有磨损均衡和预留空间机制，你往一个逻辑地址写数据，实际可能落在物理上完全不同的闪存块。覆写同一文件路径，旧数据块很可能根本没被触碰，还在某个未映射的 NAND 区域里躺着。
- Windows 的
fsutil behavior set disablelastaccess 1或trim命令无法触发对已删文件的 TRIM - 真正有效的做法是：启用卷的 TRIM 支持（
fsutil behavior query disablelastaccess确保为 0），然后依赖系统在删除时自动发送 TRIM —— 但这不保证立即执行，也不保证旧块被擦除 - 企业级场景下，应使用 SSD 厂商提供的安全擦除工具（如 Samsung Magician 的 Secure Erase），它们能发 NVMe
Format NVM命令，才是真正底层清空
所以如果你的程序运行在不确定是否为 SSD 的环境里，别指望自己写的覆写逻辑能 100% 覆盖所有情况；该交硬件处理的，就别硬扛到应用层。
