IDisposable 的本质是确保资源被可靠释放，而非简单调用 Dispose()；必须通过 using 或 try/finally 保障执行，正确实现 Dispose(bool) 模式并避免误用。
为什么 IDisposable 不等于“手动调用 Dispose()”
很多人以为只要类实现了 IDisposable，在用完后写一句 obj.Dispose() 就算完成资源释放——这是最常见也最危险的误解。真正关键的是：谁来保证这行代码一定被执行？异常发生时会不会跳过？对象被提前 GC 回收了怎么办？
正确做法是依赖语言机制保障执行时机：using 语句（编译后自动插入 try/finally），或显式 try/finally 块。哪怕你写了 Dispose() 方法，没被可靠调用就等于没写。
-
using是首选，适用于作用域明确、生命周期短的对象（如FileStream、SqlConnection） - 若对象需跨方法传递或长期持有，必须确保上层调用方负起
Dispose责任，并文档注明“此类型必须手动释放” - 不要在
Finalize（析构函数）里做核心释放逻辑——它不保证何时运行，且可能根本不会触发（对象没被 GC）
Dispose(bool) 模式里那个 disposing 参数到底控制什么
标准模板里的 protected virtual void Dispose(bool disposing)，核心分歧点就在这个 bool 参数：它不是“要不要释放”，而是“能不能访问托管资源”。
当 disposing == true，说明是用户主动调用 Dispose()（比如 using 结束），此时可以安全释放托管资源（如关闭其他 IDisposable 成员）和非托管资源；当 disposing == false，说明是 GC 在 Finalizer 线程中调用（即析构函数路径），此时托管对象可能已被回收，只能释放非托管资源（如句柄、内存指针）。
- 所有托管资源清理（如
stream?.Dispose()、timer?.Stop()）必须放在if (disposing)分支内 - 非托管资源释放（如
CloseHandle(_handle)、Marshal.FreeHGlobal(_ptr)）应放在if (!disposing)分支外，或两分支都执行（取决于资源类型） - 务必在释放后将关键字段设为
null或标记_disposed = true，并在后续方法开头加if (_disposed) throw new ObjectDisposedException(...)
继承 IDisposable 类型时，子类忘记调用 base.Dispose() 的后果
这不是“功能不完整”的问题，而是直接导致父类持有的资源泄漏。例如父类封装了一个 SafeHandle 或文件句柄，子类重写 Dispose(bool) 却没调用 base.Dispose(disposing)，那父类那部分资源永远不会释放。
更隐蔽的问题是：如果父类用了双重检查（if (_disposed) return;），而子类在调用 base.Dispose() 前就释放了自己的资源，那父类的清理逻辑可能被跳过（因为 _disposed 已被子类提前设为 true）。
- 子类
Dispose(bool)中，必须把base.Dispose(disposing)放在最后（释放自己资源之后），且不能复用父类的_disposed标记 - 推荐每个类维护自己的
_disposed字段，或使用Interlocked.CompareExchange避免重复释放 - 单元测试时，可强制触发 Finalizer（
GC.Collect(); GC.WaitForPendingFinalizers();）验证非托管资源是否真被清理
什么时候不该实现 IDisposable，哪怕它“看起来需要释放”
一个类型是否该实现 IDisposable，不取决于它“有没有资源要释放”，而取决于它是否直接拥有（own）非托管资源，或是否直接封装了其他 IDisposable 对象并对其生命周期负责。
常见误用：给纯计算类、DTO、只读配置类加上 IDisposable；或者包装一个 HttpClient 却不控制其创建/销毁——这时应该复用外部传入的实例，而不是自己 new 后又试图管理它的生命周期。
-
HttpClient是典型反例：它本身是线程安全、设计为长期复用的，自行Dispose反而引发 socket 耗尽 - 只持有
string、List<T>、Dictionary<K,V>的类，不需要IDisposable——GC 会自动回收托管内存 - 若只是“调用某个服务的
Close()方法”，但不拥有该服务实例，就不该实现IDisposable，而应在业务逻辑中明确释放责任归属
最难判断的其实是“间接持有”：比如一个类内部缓存了 MemoryStream 并反复 ToArray()，但它从不暴露流本身，也不允许外部控制其生命周期——这时它自己就是资源所有者，必须实现 IDisposable 并管理该流。
