文件句柄泄露的典型表现是报System.IO.IOException或Handle Count持续上涨超1000；确认方式包括用Process Explorer查重复句柄、加日志追踪Dispose路径、启用DOTNET_SYSTEM_IO_DISABLEFILECACHE=1暴露泄漏。
文件句柄泄露的典型表现和快速确认方式
程序运行一段时间后报 System.IO.IOException: The process cannot access the file because it is being used by another process，或在 Windows 资源监视器中看到进程的 Handle Count 持续上涨（尤其 > 1000），基本可判定存在句柄泄漏。关键不是“有没有打开文件”，而是“有没有在所有路径下都释放”。FileStream、StreamReader、StreamWriter、File.OpenRead() 等只要没显式调用 Dispose() 或进入 using 块，就大概率泄漏。
哪些写法一定会导致句柄未释放
以下代码片段在任何情况下都会泄漏句柄，哪怕逻辑看似“只读一次”：
-
var stream = File.OpenRead("log.txt");—— 没有using，没有.Dispose()，GC 不保证及时回收 -
new StreamReader("data.csv")—— 构造函数打开文件，但对象未被using包裹 -
try { var f = File.Create(path); f.Write(...); } catch {...}—— 异常时f根本没机会Dispose() - 在
foreach中反复调用File.ReadAllLines()处理大文件 —— 内部虽用using，但高频调用仍可能因 GC 滞后导致句柄堆积（尤其 .NET Framework）
诊断阶段必须做的三件事
别靠猜，直接看句柄归属：
- 用
Process Explorer（Sysinternals 工具）附加到目标进程 → View → Lower Pane View → Handles → 搜索.txt、.log等扩展名，观察相同路径句柄是否重复出现且不减少 - 在代码中临时加日志：在每次
new FileStream(...)前打时间戳 + 线程 ID，在Dispose()后打对应日志 —— 若只有前半段日志，说明该实例没走到释放路径 - 启用
DOTNET_SYSTEM_IO_DISABLEFILECACHE=1环境变量（.NET 5+）—— 关闭底层文件句柄缓存，让泄漏更早暴露，避免误判为“只是缓存延迟”
安全写法的硬性约束条件
不是“用了 using 就万事大吉”，必须满足以下全部条件：
-
using块必须包裹**最外层资源创建点**，例如using (var sr = new StreamReader(File.OpenRead(path)))是错的，应拆成using (var fs = File.OpenRead(path)) using (var sr = new StreamReader(fs))，否则File.OpenRead返回的FileStream无法被释放 - 异步方法中必须用
await using（C# 8+），而非同步using；若用Stream.ReadAsync却配同步using，可能在 await 期间发生异常导致跳过Dispose() - 自定义类封装文件操作时，必须实现
IDisposable并在Dispose()中调用内部Stream.Dispose()，不能只依赖析构函数
句柄泄漏最难 debug 的地方在于：它往往藏在深层调用链里，比如一个日志组件内部缓存了 FileStream 却忘了在应用退出时清理。所以排查时优先盯死第三方库的文档，确认其资源管理契约 —— 很多“轻量封装”根本没做 Dispose。
