软删除本质是移动而非擦除：windows回收站将文件移至$recycle.bin并记录元数据；c#无内置回收站api，需用shfileoperation或shell32.shell实现，跨平台则需自建带元数据的隐藏回收站目录。
软删除的本质是移动而非擦除
Windows 回收站不是魔法，它只是把文件移到特定系统目录（$Recycle.Bin）并记录元数据。C# 没有内置“扔进回收站”函数，System.IO.File.Delete 仍是硬删——必须自己模拟移动逻辑。
关键判断：是否在 NTFS 卷上？是否对当前用户有权限访问 $Recycle.Bin？否则 fallback 到自建回收站目录是唯一可靠路径。
- 用
SHFileOperation（Win32 API）可触发原生回收站行为，但仅限 Windows，且需 P/Invoke 和STATSHELLFILEOP权限检查 - 跨平台方案只能走“重命名 + 移动到隐藏目录”路线，比如
.trash或_recycled - 不要依赖
FileSystemWatcher监控删除事件来补救——它捕获不到Delete调用本身，只响应结果变化
用 Shell32.dll 实现真回收站（仅 Windows）
Shell32.Shell 类能绕过权限陷阱，把文件丢进当前用户的 $Recycle.Bin 并保留原始路径信息。但它不抛异常，失败时静默失败——这是最常踩的坑。
实操要点：
- 引用 COM 组件：添加对
Shell32的引用（.NET Framework）或用Microsoft.WindowsAPICodePack-Shell（.NET Core/5+） - 必须用
Folder.MoveHere方法，传入带完整路径的string，不能用Uri或相对路径 - 检查返回值：如果
MoveHere返回null或空集合，说明操作被拒绝（如目标在只读卷、U 盘、网络驱动器） - 示例：
var shell = new Shell32.Shell(); var desktop = shell.NameSpace(0); // 桌面 desktop.MoveHere(@"C:\temp\test.txt", 4 | 16); // FOF_NOCONFIRMATION | FOF_SILENT
Fallback 方案：自己管回收站目录
当 Shell32 不可用或跨平台时，你得自己维护一个“回收站”。重点不是存文件，而是存上下文——否则用户恢复时不知道该放回哪。
必须记录的信息：
- 原始绝对路径（
OriginalPath） - 删除时间（
DeletedAt） - 唯一 ID（建议用
Guid，避免同名文件覆盖） - 可选：原始文件大小、哈希（用于去重或校验）
目录结构建议：
.recycle/
├── 2024-06-15_abc123/
│ ├── metadata.json
│ └── test.txt
└── 2024-06-15_def456/
├── metadata.json
└── report.pdf
不要把所有文件扁平扔进一个文件夹——恢复时无法区分来源。
恢复文件时容易忽略的权限和路径问题
从回收站还原，不是简单 File.Move 回去。原始路径可能已不存在、父目录无写入权、甚至盘符已被拔掉。
安全做法：
- 先用
Directory.Exists(Path.GetDirectoryName(originalPath))检查父目录是否存在 - 若不存在，递归创建（
Directory.CreateDirectory），但注意：不要盲目创建 C:\Program Files 这类受保护路径 - 用
File.GetAttributes检查目标是否为只读/隐藏/系统文件，还原前清除FileAttributes.ReadOnly - 若原始路径是符号链接或挂载点，
File.Move会失败——此时应复制内容再删源，而不是移动
复杂点在于：回收站本身也得清理。自动清空策略（如 30 天）必须用独立线程或定时任务跑，不能卡在 UI 线程里；而且清理前要确认文件没被其他进程锁住——IOException 是常态，得重试或跳过。
