IDisposable用于及时释放非托管资源，避免文件句柄、数据库连接等泄漏，GC不管理这些资源；通过using语句或Dispose模式确保显式清理，防止资源占用；终结器不可靠，需主动调用Dispose；托管内存由GC回收，无需手动置null；正确实现包括释放非托管资源、调用GC.SuppressFinalize及使用_disposed标志防重复释放。
IDisposable 接口不是用来“管理托管资源”的，而是为了**及时释放非托管资源**，并提供一种可预测的、显式的清理时机。.NET 的垃圾回收器（GC）只负责回收托管内存，对文件句柄、数据库连接、窗口句柄、网络套接字等非托管资源完全无感——这些必须手动释放，否则极易引发资源泄漏。
为什么需要 IDisposable 和 using？
不实现 IDisposable 或不调用 Dispose()，非托管资源可能长时间滞留：一个未关闭的文件流会锁住文件；未释放的 GDI 句柄会导致 UI 界面卡顿甚至崩溃；未关闭的数据库连接会快速耗尽连接池。GC 虽然最终会通过终结器（Finalizer）尝试兜底，但时机不可控、效率低，且不能保证执行——所以不能依赖它做关键清理。
托管资源通常不需要手动释放
普通引用类型（如 List
正确实现 IDisposable 的核心要点
- 声明 IDisposable 接口，并提供公共 Dispose() 方法
- 使用 bool _disposed 标志防止重复释放（尤其在终结器中被再次调用时）
- 释放非托管资源（如调用 CloseHandle()、sqlite3_close()）和托管资源（如调用 stream.Dispose()、connection.Close()）
- 在 Dispose(bool disposing) 模式中：当 disposing == true 时可安全调用其他托管对象的 Dispose()；为 false 时（即从终结器调用），只释放非托管资源
- 调用 GC.SuppressFinalize(this) 防止对象进入终结队列，提升性能
using 语句是语法糖，但强烈推荐
using (var file = new FileStream("log.txt", FileMode.Create)) { ... } 编译后等价于 try/finally 块，确保 Dispose() 总被执行，哪怕中间抛出异常。它比手写 finally 更简洁、不易出错。对于只用一次的资源（尤其是 I/O、数据库、图形设备），using 是首选方式。
若需跨作用域复用资源，可手动调用 Dispose()，但务必确保调用时机明确、路径唯一（例如在方法末尾或 catch 后），避免遗漏。
基本上就这些。IDisposable 不复杂，但容易忽略它的设计本意——它不是给托管内存用的，而是为操作系统级资源守门的。用好 using，写对 Dispose 模式，程序才真正“收得干净”。
