c# iidisposable 接口怎么用

必须实现IDisposable：当类直接持有非托管资源或封装了IDisposable对象时，否则会导致资源泄漏；using仅对括号内声明的IDisposable变量生效；Dispose(bool)分离托管与非托管释放逻辑，析构函数仅作最后保障。

什么时候必须实现 `IDisposable`？

当你类里直接持有非托管资源（比如 IntPtr、文件句柄、Win32 API 分配的内存），或封装了其他实现了 IDisposable 的对象（如 FileStream、SqlConnection），就必须实现它。否则资源不会被及时释放，轻则文件被锁、连接池耗尽，重则进程句柄泄漏导致系统变慢甚至崩溃。

✅ 必须实现：类自己调用 Marshal.AllocHGlobal、CreateFile 等 Win32 函数
✅ 必须实现：内部 new 了 MemoryStream、HttpClient（注意：不是所有托管类型都需手动释放，但长期存活且包装了非托管资源的要管）
❌ 不必实现：只含普通字段（string、int、List）且没引用任何 IDisposable 对象的类

`using` 语句怎么写才真正安全？

using 是最常用也最容易误用的点——它只对“声明在 using 括号内”的变量生效，且要求该变量类型明确实现 IDisposable。一旦你把它当 try-finally 用却忘了类型约束，就可能白忙一场。

✅ 正确：

using (var stream = new FileStream("log.txt", FileMode.Create))
{
    stream.Write(data, 0, data.Length);
} // 这里自动调用 stream.Dispose()

❌ 错误：

FileStream stream = null;
using (stream = File.OpenRead("data.bin")) // 编译失败！不能赋值给已声明变量
{
    // ...
}

⚠️ 隐患：如果 Dispose() 方法抛异常（比如网络流关闭时底层 socket 已断），using 会把异常暴露出来——别假设它一定静默；必要时在外层加 try/catch

完整 `Dispose` 模式为什么需要 `Dispose(bool)` 和析构函数？

因为 GC 不保证何时回收对象，而析构函数（~MyClass()）是最后的安全网，仅用于释放非托管资源；Dispose(bool) 则让“显式释放”和“GC 回收时释放”两条路径复用同一套逻辑，避免重复清理或遗漏。

✅ disposing == true：可安全调用其他托管对象的 Dispose()（比如 _file?.Dispose()）
✅ disposing == false：只能释放非托管资源（如 Marshal.FreeHGlobal(_ptr)），绝不能访问托管字段（此时它们可能已被 GC 回收）
✅ 必须调用 GC.SuppressFinalize(this)：显式调用了 Dispose() 后，告诉 GC “不用再跑析构函数了”，避免双重释放
⚠️ 常见坑：在析构函数里调用了 Dispose(true) ——这会导致托管资源被二次释放，引发 ObjectDisposedException

子类继承时如何安全重写 `Dispose`？

父类若设计为可继承，必须把 Dispose(bool) 设为 protected virtual；子类重写时，要在释放自身资源后调用 base.Dispose(disposing)，确保父类逻辑被执行，且顺序正确（子类先清，父类后清）。

✅ 正确模式：

public class DerivedResource : BaseResource
{
    private FileStream _childStream;
    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            _childStream?.Dispose(); // 先释放子类托管资源
        }
        base.Dispose(disposing); // 再交给父类处理
    }
}