IFormFile上传的临时文件不会自动删除，需显式处理；小文件走内存缓冲，大文件写入系统临时目录，但GC不保证及时清理，必须在业务处理完成后同步删除或改用Request.Body手动管理流。
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，别让它变成黑洞。
