idisposable 是资源生命周期控制机制，dispose(bool disposing) 中 bool 参数控制能否安全访问托管对象：true 时可释放托管和非托管资源，false 时仅释放非托管资源；必须设 _disposed = true 并防护调用，且在 public dispose() 首行调用 gc.suppressfinalize(this)；子类须调用 base.dispose(disposing)；using 在对象逃逸、异步路径遗漏或嵌套异常时失效。
IDisposable 不是“写个 Dispose() 就完事”的接口，而是整套资源生命周期控制机制——不按标准模式实现，轻则重复释放报错，重则非托管资源永久泄漏。
Dispose(bool disposing) 里的 bool 参数到底控制什么
它不是“要不要释放”，而是“能不能安全访问托管对象”。
当 disposing == true，说明是用户主动调用（比如 using 结束或手动调用 Dispose()），此时可以放心释放托管资源（如 _stream?.Dispose()、_timer?.Stop()）和非托管资源；
当 disposing == false，说明是 GC 在终结器线程中回调（即析构函数路径），此时托管对象可能已被回收，只能释放非托管资源（如 CloseHandle(_handle)、Marshal.FreeHGlobal(_ptr)）。
- 所有托管资源清理逻辑必须包裹在
if (disposing)分支内 - 非托管资源释放可放在分支外，或两分支都执行（取决于资源是否线程安全/可重入）
- 释放后务必设
_disposed = true或将关键字段置为null，并在后续方法开头加防护：if (_disposed) throw new ObjectDisposedException(...)
为什么必须调用 GC.SuppressFinalize(this)
终结器（~MyClass()）只是后备手段，它不确定何时运行，甚至可能永不触发。一旦你已显式释放了非托管资源，就该告诉 GC：“别再调我终结器了”。
GC.SuppressFinalize(this) 必须在 Dispose() 入口处调用，且只调一次——否则终结器仍可能被调度，导致非托管资源二次释放（如重复 CloseHandle）引发未定义行为。
- 不调用
SuppressFinalize→ 终结器可能 later 执行 → 非托管资源被释放两次 - 在
Dispose(bool)里调用 → 错误，因为Dispose(false)是终结器路径，此时不该抑制自己 - 只在 public
Dispose()方法第一行调用才正确
子类继承 IDisposable 类型时最容易漏掉的一步
子类重写 Dispose(bool) 后，忘记调用 base.Dispose(disposing)，等于直接放弃父类持有的所有资源。
更隐蔽的问题是释放顺序：如果子类在调用 base.Dispose(disposing) 前就把自己字段设为 null 或标记 _disposed = true，而父类的 Dispose(bool) 里又有 if (_disposed) return; 检查，那父类的清理逻辑就会被跳过。
- 子类释放自身资源 → 然后立即调用
base.Dispose(disposing) - 父类的
Dispose(bool)必须也遵循相同模式，并检查_disposed标志 - 若父类用了
SafeHandle等封装类型，不调base.Dispose就等于句柄永远不 Close
using 语句失效的三种真实场景
using 看似万能，但在以下情况它救不了你：
- 对象被返回出方法（如工厂方法返回
IDisposable实例），调用方没用using包裹 → 资源泄漏 - 异步方法中直接
await using未覆盖全部路径（比如catch块里提前 return）→DisposeAsync可能不执行 - 多个
using嵌套时，内层Dispose()抛异常 → 外层Dispose()被跳过（C# 默认不聚合异常）
这些地方必须退回到显式 try/finally，并在 finally 中确保 Dispose() 调用 —— 而且最好在 Dispose(bool) 内部用 try/catch 吞掉非关键释放异常，避免掩盖原始错误。
