SafeFileHandle 是什么，为什么不能直接用 IntPtr
SafeFileHandle是 .NET 提供的用于封装 Windows 文件句柄（
HANDLE）的安全包装器，它实现了
IDisposable并参与 .NET 的垃圾回收生命周期管理。直接用
IntPtr存储句柄会导致资源泄漏或双重关闭——因为 GC 不知道该何时释放、也无法保证只释放一次。
常见错误现象：
ObjectDisposedException、
IOException（“句柄无效”）、程序在高并发文件操作时偶发崩溃。 必须继承
SafeHandle并重写
ReleaseHandle()，而
SafeFileHandle已为你做好了：它调用
CloseHandle()且能正确处理
INVALID_HANDLE_VALUE构造时必须传入有效的非托管句柄，并设
ownsHandle = true（表示托管层负责释放），否则 GC 不会触发清理 一旦调用
Dispose()或被 GC 回收，内部
handle会被置为
IntPtr.Zero，再次访问会抛
ObjectDisposedException
如何从 CreateFile 获取 SafeFileHandle
Windows API 的
CreateFile返回
IntPtr，你需要把它转成
SafeFileHandle实例——但不能直接 new，必须用它的受保护构造函数，所以得自己封装一层子类，或使用 .NET 5+ 提供的
SafeFileHandle(IntPtr, Boolean)公共构造函数。
示例（.NET 6+）：
var handle = CreateFile(
@"C:\test.bin",
FileAccess.GenericWrite,
FileShare.None,
IntPtr.Zero,
FileMode.Create,
FileAttributes.Normal,
IntPtr.Zero);
if (handle == InvalidHandleValue)
throw new IOException($"CreateFile failed: {Marshal.GetLastWin32Error()}");
var safeHandle = new SafeFileHandle(handle, ownsHandle: true); // ⚠️ ownsHandle 必须为 true
ownsHandle: true表示这个
SafeFileHandle拥有并负责释放该句柄；若为
false，你得自己调用
CloseHandle，且
SafeFileHandle不会帮你关 不要在
CreateFile失败后仍传入
InvalidHandleValue构造
SafeFileHandle，它不会报错，但后续
Dispose()会调用
CloseHandle(INVALID_HANDLE_VALUE)，引发 Win32 错误 建议立即检查
handle == InvalidHandleValue，再构造
SafeFileHandle
配合 FileStream 使用 SafeFileHandle
FileStream有接受
SafeFileHandle的构造函数，这是将非托管句柄接入托管 I/O 生态的关键入口。它让
FileStream接管底层句柄的生命周期，避免你手动管理
Dispose顺序问题。
示例：
using var fs = new FileStream(safeHandle, FileAccess.Write, bufferSize: 4096, isAsync: true); fs.Write(data, 0, data.Length); // safeHandle 自动随 fs.Dispose() 被释放传入的
SafeFileHandle必须是
ownsHandle: true，否则
FileStream构造时会抛
ArgumentException（提示 “Safe handle must be initialized”） 不要对同一个
SafeFileHandle创建多个
FileStream，这会导致重复释放或句柄被提前关闭 如果需要异步 I/O，务必设
isAsync: true，否则即使调用
WriteAsync也会退化为同步阻塞
常见陷阱：跨线程传递、重复释放、GC 延迟
SafeFileHandle不是线程安全的：虽然其内部
handle字段是原子读写的，但
Dispose()和
IsInvalid判断之间存在竞态窗口。更关键的是，GC 触发时机不可控，依赖 Finalizer 释放句柄属于高危行为。 永远显式调用
Dispose()或用
using，不要等 Finalizer —— Finalizer 线程调用
CloseHandle可能失败（如进程已退出 DLL 上下文） 避免把
SafeFileHandle存进静态集合或跨线程共享，除非你加锁或确保只读（例如仅用于
get_Handle()查看值） 调试时可用
safeHandle.IsInvalid或
safeHandle.IsClosed判断状态，但别用
safeHandle.DangerousGetHandle()后自行调用
CloseHandle—— 这绕过了安全机制 如果句柄来自第三方库（如某些硬件 SDK），确认它是否要求调用方释放；若不明确，先设
ownsHandle: false，并在文档/测试验证后再改 实际项目中最容易被忽略的，是
ownsHandle的语义和
SafeFileHandle构造时机的耦合——句柄有效性、所有权归属、托管对象生命周期，三者必须严格对齐，差一点就会在压力测试中暴露为偶发句柄泄漏或访问违规。
