双泄漏确认需同步验证句柄与内存同源同频同路径：用Process Explorer查.tmp/.part句柄增长，Performance Monitor绘HandleCount与GC内存曲线，开启DOTNET_SYSTEM_IO_DISABLEFILECACHE=1暴露泄漏。
排查第三方文件上传组件引发的临时文件句柄与内存双泄漏，关键在于同步验证句柄增长和内存堆积是否同源、同频、同路径。不能只盯内存或只看句柄——很多情况下，句柄未关会导致文件流对象无法被 GC 回收，形成“句柄锁住内存”的耦合泄漏。
确认双泄漏现象是否真实存在
先排除误判：
- 在 Windows 上，用 Process Explorer（Sysinternals）附加目标进程 → View → Lower Pane View → Handles → 搜索
.tmp、.part、upload等关键词，观察句柄数是否随每次上传稳定+1且不回落； - 同时打开 Performance Monitor 或写一行日志：每 10 秒记录
Process.GetCurrentProcess().HandleCount和GC.GetTotalMemory(false)，画出两条曲线——若两者同步阶梯式上升，基本坐实双泄漏； - 禁用 .NET 文件缓存干扰：启动前设置环境变量
DOTNET_SYSTEM_IO_DISABLEFILECACHE=1（.NET 5+），让泄漏立刻暴露，避免误以为是“缓存延迟释放”。
定位泄漏源头在第三方组件哪一层
多数上传组件泄漏发生在三类位置：临时文件创建、流包装、异步上下文丢失。按优先级排查：
- 检查组件是否调用
Path.GetTempFileName()或File.CreateTempFile()后未配对File.Delete()，尤其在异常分支（如校验失败、大小超限）中遗漏清理； - 查看它返回的
Stream是否被多层包装（如BufferedStream→GZipStream→FileStream），但只对最外层调用了Dispose()，内层原始句柄仍挂着； - 若组件提供异步 API（如
UploadAsync()），确认它内部是否使用了Task.Run()或线程池回调——这些场景下using块可能因异常提前跳出，或await using未被正确实现。
运行时抓取泄漏实例与调用栈
不用等程序崩，主动捕获正在泄漏的对象：
- 用 PerfView 录制 30 秒内存分配 + 句柄事件：
Collect -NoGui -AcceptEula -ThreadTime -HeapStat，然后分析 “Allocations by Stack” 中高频出现的FileStream、TempFileCollection、组件命名空间类； - 用 WinDbg Preview 附加进程，执行：
!htrace -enableg（运行几十秒上传操作）.break!htrace
查看输出中是否有大量CreateFile调用无对应CloseHandle，并记下其调用栈中的第三方组件方法名； - 对疑似对象加条件断点：比如在 Visual Studio 中，在组件源码或反编译代码里，对
new FileStream(...)行设断点，观察每次上传是否都进入、是否都走到Dispose()，特别注意catch块和finally外的 return。
验证修复与规避方案
临时绕过问题组件，也能帮你交叉验证：
- 改用
IFormFile.OpenReadStream()+ 手动流复制到MemoryStream（小文件）或带using的FileStream（大文件），对比句柄/内存是否平稳； - 若必须用该组件，强制接管其临时文件生命周期：监听组件的
OnFileUploaded事件后，立即扫描Path.GetTempPath()下最新生成的.tmp文件，用File.Exists() && !IsFileLocked()辅助判断是否可删； - 上线前加守护逻辑：后台线程每分钟检查
Process.HandleCount > 2000且GC.GetTotalMemory(true) > 500MB，触发告警并自动调用GC.Collect()+GC.WaitForPendingFinalizers()（仅应急，不替代修复）。
