ASP.NET Core 中 IFormFile
上传后临时文件何时释放
ASP.NET Core 默认将上传的
IFormFile内容缓存在内存或磁盘临时目录中，具体取决于文件大小和配置。小于
64 KB（默认阈值）走内存缓冲，大于则写入系统临时目录（如
/tmp或
%TEMP%），但这个临时文件**不会自动删除**——它只在请求结束、
IFormFile对象被 GC 回收时才可能清理，而 GC 时间不可控，尤其在高并发或大文件场景下容易堆积。
常见错误现象：上传接口反复调用后，
/tmp目录出现大量类似
dotnet-aspnetcore-XXXXX的残留文件；Linux 上磁盘空间告警；Windows 上因防病毒软件扫描临时文件导致上传卡顿。 必须显式读取并处理内容（如
CopyToAsync或
OpenReadStream()），否则底层流可能未触发清理逻辑 不要依赖
using (var stream = file.OpenReadStream())自动释放临时文件——它只释放流，不删磁盘文件 若中途抛异常未完成读取，临时文件几乎必然残留，需额外兜底
手动清理临时文件的可靠时机与方式
最安全的做法是在完成业务处理（保存到目标位置、校验通过、事务提交）后，**同步删除原始临时文件**。但
IFormFile不暴露临时路径，所以得绕道：使用
file.CopyToAsync到自定义
FileStream，或改用底层
HttpContext.Request.Body流控制。
更实用的方案是禁用默认临时缓存，全程自己管理：
在Program.cs中配置
FormOptions：
builder.Services.Configure<FormOptions>(options =>
{
options.MemoryBufferThreshold = int.MaxValue; // 强制全部进内存（仅适用于小文件）
// 或设为 0 并自行处理流，避免磁盘临时文件
});
对大文件，直接读取 HttpContext.Request.Body，配合
FileStream写入目标路径，跳过
IFormFile的中间层 若仍用
IFormFile，且确认已完整读取（如
await file.CopyToAsync(destStream)），可尝试反射获取内部
_file字段的
TempFileName（.NET 6+ 已移除该字段，不推荐）
使用 FileStream
+ TempDirectory
手动接管临时存储
当需要预处理（如病毒扫描、格式转换、分片合并）时，应主动创建受控临时文件，而非依赖框架隐式行为。用
Path.GetTempFileName()或
Path.Combine(Path.GetTempPath(), Guid.NewGuid().ToString())生成路径，明确生命周期。 务必用
try/finally或
using确保
FileStream关闭后再删文件：
var tempPath = Path.Combine(Path.GetTempPath(), $"{Guid.NewGuid()}.tmp");
using var fs = File.Create(tempPath);
await file.CopyToAsync(fs); // 完整写入
// ... 处理逻辑
finally
{
if (File.Exists(tempPath)) File.Delete(tempPath);
}
避免在 catch块里删文件——异常可能发生在写入中途，文件不完整，但删了就丢失线索；建议先记录日志再删 Linux 上注意
/tmp可能被
systemd-tmpfiles清理，不要假设文件能长期存在
跨请求临时文件的生命周期与清理策略
如果上传需分步（如先存临时区、再审核通过后转正），就不能依赖单次请求生命周期。此时必须引入外部管理机制。
用独立后台服务（如IHostedService）定期扫描
TempDirectory中超过 24 小时的文件并删除 将临时文件元数据（路径、创建时间、关联用户ID）存入数据库，清理时先查库再删盘，避免误删正在使用的文件 不要把临时文件放在 Web 应用工作目录下（如
wwwroot/temp），易被直接 HTTP 访问，有安全风险
真正麻烦的不是“怎么删”，而是“删早了”或“删晚了”——前者导致后续步骤找不到文件，后者拖垮磁盘。所有临时路径都应有明确归属标识和 TTL，别让它变成黑洞。
