什么时候必须实现 IDisposable
？
当你类里直接持有非托管资源（比如
IntPtr、文件句柄、Win32 API 分配的内存），或封装了其他实现了
IDisposable的对象（如
FileStream、
SqlConnection），就必须实现它。否则资源不会被及时释放，轻则文件被锁、连接池耗尽，重则进程句柄泄漏导致系统变慢甚至崩溃。 ✅ 必须实现：类自己调用
Marshal.AllocHGlobal、
CreateFile等 Win32 函数 ✅ 必须实现：内部 new 了
MemoryStream、
HttpClient（注意：不是所有托管类型都需手动释放，但长期存活且包装了非托管资源的要管） ❌ 不必实现：只含普通字段（
string、
int、
List<t></t>）且没引用任何
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); // 再交给父类处理
}
}
⚠️ 危险操作：子类重写 Dispose()方法本身（而非
Dispose(bool)），会绕过整个模式，导致
GC.SuppressFinalize失效、析构函数仍可能执行 ⚠️ 忽略标志位：
_disposed必须在基类中统一维护，子类不应另起一套判断逻辑 真正难的不是写对模板，而是判断“这个字段到底要不要 Dispose”——比如
HttpClient实例是否该由你释放？答案取决于它是不是你 new 出来的、生命周期是否由你控制。这类边界问题没有银弹，得看文档、看源码、看调用上下文。
