SafeFileHandle 是 .NET 对操作系统文件句柄生命周期的显式管理契约，继承自 SafeHandle，强制实现 ReleaseHandle() 并提供双重释放防护与终结器兜底；直接用 IntPtr 易致句柄泄漏，必须校验非 INVALID_HANDLE_VALUE 后以 ownsHandle: true 构造，并配合 using 或 IDisposable 正确释放。
SafeFileHandle 是什么，为什么不能直接用 IntPtr
它不是句柄的“包装器”，而是 .NET 对操作系统句柄生命周期的显式管理契约。直接用 IntPtr 持有文件句柄（比如从 CreateFile 返回）会导致 GC 无法感知资源释放时机，一旦忘记调用 CloseHandle，句柄就泄漏——Windows 单进程句柄数有限（默认约 16K），泄漏多了会触发 IOException：“The handle is invalid” 或 “Not enough storage is available to process this command”。SafeFileHandle 继承自 SafeHandle，强制要求重写 ReleaseHandle()，且自带双重释放防护和终结器兜底。
如何正确构造 SafeFileHandle 实例
不要自己 new SafeFileHandle 然后塞个 IntPtr 进去——必须传入有效的、已打开的句柄，并明确指定 ownsHandle 参数含义：
-
ownsHandle = true：表示该SafeFileHandle拥有句柄所有权，Dispose 或终结时会自动调用CloseHandle -
ownsHandle = false：仅用于封装外部传入的、由别处管理生命周期的句柄（极少见，如互操作中需临时借用） - 必须在构造时传入非无效句柄：
INVALID_HANDLE_VALUE（即(IntPtr)(-1)）会导致构造失败抛ArgumentException
典型安全写法：
var handle = CreateFile(
path,
FileAccess.Read,
FileShare.None,
IntPtr.Zero,
FileMode.Open,
FileAttributes.Normal,
IntPtr.Zero);
if (handle == INVALID_HANDLE_VALUE)
throw new IOException($"Failed to open file: {Marshal.GetLastWin32Error()}");
var safeHandle = new SafeFileHandle(handle, ownsHandle: true); // ✅ 关键：true
配合 FileStream 使用时的常见误区
.NET 6+ 的 FileStream 支持直接接收 SafeFileHandle 构造，这是最推荐的路径；但要注意：
- 不要把同一个
SafeFileHandle实例重复传给多个FileStream——第二个会因句柄已被关闭而抛ObjectDisposedException - 不要在
FileStream未 Dispose 前手动调用safeHandle.Dispose()，否则流读写会立即失败 - 若用
FileStream构造后还需底层句柄操作（如SetFilePointerEx），应通过fileStream.SafeFileHandle获取，而非保存原始SafeFileHandle变量——因为后者可能已被流内部 Dispose
正确示例：
using var safeHandle = new SafeFileHandle(handle, ownsHandle: true); using var fs = new FileStream(safeHandle, FileAccess.Read, bufferSize: 4096, isAsync: true); // 后续所有 I/O 都走 fs，无需再碰 safeHandle
不使用 FileStream 时如何确保 SafeFileHandle 被释放
裸用 SafeFileHandle（比如只做 DeviceIoControl 调用）必须严格遵循 using 或 try/finally：
- 不能依赖终结器兜底——它不保证及时性，高负载下句柄可能堆积数秒甚至更久
- 如果句柄被封装进自定义类，该类必须实现
IDisposable，并在Dispose()中调用safeHandle.Dispose() - 避免在异步方法中捕获
SafeFileHandle后跨 await 边界持有——await 可能切换上下文，增加意外泄露风险
关键点：只要 SafeFileHandle 实例还活着，且 ownsHandle == true，它的释放就只应发生一次，且应由你主动控制。
最容易被忽略的是：在 P/Invoke 场景中，有人把 CreateFile 返回的 IntPtr 直接丢给 SafeFileHandle 构造却不检查是否为 INVALID_HANDLE_VALUE，结果构造成功但内部句柄无效，后续任何操作都失败，错误信息却指向下游 API 而非源头。务必在构造前校验句柄有效性。
