直接调用 File.Delete 会出问题。最常见的是抛出 UnauthorizedAccessException 或 IOException，比如文件正被其他进程占用、权限不足、路径不存在或只读属性未清除。
直接调用 File.Delete 会出问题吗？
会。最常见的是抛出 UnauthorizedAccessException 或 IOException，比如文件正被其他进程占用、权限不足、路径不存在或只读属性未清除。C# 的 File.Delete 是“硬删”，不检查前置状态，失败即崩，不适合生产环境直接裸用。
删除前必须检查的三件事
安全删除不是加个 try-catch 就完事，得主动验证关键条件：
-
File.Exists(path)—— 避免对空路径或不存在文件调用Delete（否则抛FileNotFoundException） -
File.GetAttributes(path)是否包含FileAttributes.ReadOnly—— 若有，必须先用File.SetAttributes(path, FileAttributes.Normal)清掉，否则删失败 - 确认当前进程对目标目录有写权限（尤其在 Windows 服务、IIS 或受限用户下运行时）—— 这无法用 .NET API 精确预判，但可通过尝试写同目录临时文件间接试探
带重试和日志的实用删除封装
以下是一个轻量但可靠的删除辅助方法，处理了占用、只读、权限等典型场景：
public static bool SafeDeleteFile(string path, int maxRetries = 3, int delayMs = 100)
{
if (string.IsNullOrEmpty(path) || !File.Exists(path))
return true; // 不存在视为“已删除”
<pre class="brush:php;toolbar:false;">for (int i = 0; i <= maxRetries; i++)
{
try
{
var attr = File.GetAttributes(path);
if ((attr & FileAttributes.ReadOnly) == FileAttributes.ReadOnly)
File.SetAttributes(path, attr & ~FileAttributes.ReadOnly);
File.Delete(path);
return true;
}
catch (IOException ex) when (ex.Message.Contains("being used") || ex.HResult == -2147024891) // 0x80070005 / 0x80070020
{
if (i == maxRetries) throw;
Thread.Sleep(delayMs * (int)Math.Pow(2, i)); // 指数退避
}
catch (UnauthorizedAccessException)
{
throw; // 权限问题不重试，需人工介入
}
}
return false;}
注意：重试只针对“文件被占用”类错误；HResult == -2147024891 是 Windows ERROR_SHARING_VIOLATION 的典型值，比字符串匹配更可靠。
异步删除要注意什么？
File.Delete 本身没有异步版本（.NET 6+ 仍无 File.DeleteAsync），强行套 Task.Run(() => File.Delete(...)) 只是线程池搬运工，并不真正异步，还可能掩盖异常上下文。如需非阻塞，应：
- 在 I/O 密集型服务中，优先考虑是否真需要“删完再往下走”——很多场景可改为后台队列延迟删除
- 若必须异步，用
Task.Run包裹时务必保留原始异常类型（别用await Task.Run(...)吞掉IOException层级） - 避免在 ASP.NET Core 请求作用域内启动长期
Task.Run，防止请求结束但删除仍在后台跑
真正棘手的从来不是“怎么删”，而是“删之前没确认谁在锁它”和“删之后没验证是否真没了”。尤其在多进程共享文件的场景（如日志轮转、配置热更新），删完立刻 File.Exists 再验一次，比任何重试逻辑都实在。
