IDisposable是.NET中释放非托管资源的必需机制，非调用即致资源泄漏；using语句通过编译器生成try/finally确保Dispose()必执行，比手动调用更可靠；标准Dispose模式需用disposed标志防重复释放，并调用GC.SuppressFinalize避免终结器二次清理。
IDisposable 不是“可选优化”，而是资源泄漏的开关——只要对象持有文件句柄、数据库连接、Socket 或非托管内存，不调用 Dispose() 就等于把资源锁死在进程里，直到程序退出。
为什么 using 语句比手动调用 Dispose() 更可靠
手动调用 Dispose() 看似直接，但实际容易漏掉异常路径下的清理。而 using 本质是编译器生成的 try/finally 块，确保无论是否抛异常，Dispose() 都会被执行。
- 以下写法等价于显式
try/finally，但更简洁、不易出错：
using (var stream = new FileStream("data.txt", FileMode.Open))
{
// 可能抛出 IOException
Process(stream);
} // ← 这里自动调用 stream.Dispose()
- 如果类型没有无参构造函数，或需延迟初始化，可用声明式
using（C# 8+）：
using var db = new SqlConnection(connStr); db.Open(); // ... 使用后自动释放
- 注意：不能对已 dispose 的对象再次调用
Dispose()—— 虽然多数实现是幂等的，但部分底层资源（如某些 COM 对象）会直接抛ObjectDisposedException。
IDisposable 实现里为什么总要写 disposed 标志和 GC.SuppressFinalize
这是防止双重释放和终结器干扰的关键组合。没有它，Dispose() 可能被 GC 在 finalizer 线程里再调一次，引发竞态或崩溃。
-
disposed字段（通常为private bool disposed = false;）用于标记资源是否已释放，避免重复操作 -
GC.SuppressFinalize(this)必须在Dispose(true)后立即调用，告诉 GC：“别再排队调我的析构函数了” - 析构函数（
~MyClass()）只应调用Dispose(false)，且仅释放非托管资源（此时托管对象可能已被回收，不能访问其他托管字段）
哪些类型必须用 using 或 Dispose，哪些可以不管
判断依据不是“类名有没有 Stream 或 Connection”，而是看它是否实现了 IDisposable 接口——查文档或 IDE 提示最准。
- 必须处理的典型类型：
FileStream、SqlConnection、HttpClient（长期复用时除外）、Graphics、Timer - 常见误区：
List<T>、Dictionary<TKey, TValue>、StringBuilder—— 它们不实现IDisposable，无需也不该调用Dispose() - 特别注意：
HttpClient实例本身是线程安全且建议复用的，但如果你把它声明为局部变量并 new 出来，就必须using；若作为静态或单例，则不应 dispose（否则后续请求失败）
Dispose 模式中 disposing 参数到底控制什么
protected virtual void Dispose(bool disposing) 是标准模板的核心，disposing 参数区分了调用来源：是用户主动调用 Dispose()（true），还是 GC 调析构函数（false）。
- 当
disposing == true：可安全释放托管资源（如调用_stream?.Dispose()、_timer?.Dispose()） - 当
disposing == false：只能释放非托管资源（如CloseHandle(_handle)），因为此时托管对象可能已被 GC 回收，访问字段会触发NullReferenceException - 这个参数不是“要不要释放”的开关，而是“能不能访问托管对象”的边界
真正容易被忽略的是：即使写了完整 Dispose 模式，如果忘了在 Dispose(true) 后调 GC.SuppressFinalize(this)，析构函数仍会排队执行，导致非托管资源被释放两次——尤其在高并发或低内存压力下，这种问题往往延迟暴露，排查成本极高。
