idisposable 的核心是明确资源所有权和释放时机，而非仅实现 dispose 方法；必须用 using 的场景是对象生命周期严格限定在作用域内，如 filestream、sqlconnection 等；非 owned 对象（如 di 注入）不应手动释放。
IDisposable 不是“必须手动调用 Dispose 才算正确”，而是“必须确保 Dispose 被调用，且只在对象所有权明确、不再使用时调用”——绝大多数场景下，using 语句就是最直接、最安全的解法。
什么时候必须用 using 语句？
只要对象实现了 IDisposable，且它的生命周期**严格限定在某个作用域内（比如一个方法里打开、读完就关）**，就必须用 using。这不是建议，是防止资源泄漏的实际需要。
- 常见类型：
FileStream、StreamReader、SqlConnection、HttpClient（注意：HttpClient实例通常不应每次请求都新建+using，但这是例外，不是规则） - 不满足条件就不该用：比如对象被注入到类中作为字段长期持有，或跨多个方法共享，此时由容器或更高层负责释放
-
using声明（无大括号）和using语句（带大括号）行为一致，但前者作用域是整个 enclosing block，后者更显式、更易读
Dispose() 被调用后还能访问对象吗？
能访问，但大概率会抛出 ObjectDisposedException —— 这不是 bug，是设计使然。实现者应在所有公共方法开头检查 _disposed 标志并抛异常。
- 典型错误：在
using块外继续使用已释放的StreamReader，运行时报Cannot access a closed TextReader - 关键点：释放 ≠ 对象内存被回收，只是它内部状态被标记为“无效”，后续调用会快速失败，避免静默错误或未定义行为
- 不要依赖 GC 或析构函数来“兜底”：GC 不保证何时运行，析构函数不能访问托管对象，且可能根本不会触发
为什么 CA2213 警告总在报 ManualResetEvent、Semaphore 这些小对象？
因为它们确实持有操作系统句柄，.NET 要求你明确释放 —— 但你得先判断：这个对象是不是你“拥有”的？
- 如果你 new 出来、自己保存引用、自己决定何时不用了 → 必须
Dispose()（用using或try/finally） - 如果你只是接收参数、传给别的 API、或由 DI 容器管理 → 不用管，容器或调用方负责
- 过度响应警告的典型反模式：
new ManualResetEvent(false).Dispose()—— 这个对象刚创建就释放，毫无意义，还可能掩盖真正该释放的地方 - Roslyn 的 CA2213 是静态分析，它无法理解所有权语义，只能按“有字段就提醒”，你需要人工判断
IAsyncDisposable 和 await using 怎么配合？
只有当你处理的对象释放操作本身是异步的（比如要等待网络连接优雅关闭、刷写磁盘缓存），才需要 IAsyncDisposable；同步资源一律用 IDisposable + using。
-
await using只对实现IAsyncDisposable的类型有效，对普通IDisposable会编译失败 - 如果一个类同时实现
IDisposable和IAsyncDisposable，调用方必须根据上下文选对语法：using对应Dispose()，await using对应DisposeAsync() - 切忌只实现
IAsyncDisposable却不实现IDisposable：同步上下文（如构造函数失败回滚、try/finally）无法触发清理，必然泄漏
最容易被忽略的一点：IDisposable 的核心从来不是“怎么写 Dispose 方法”，而是“谁负责释放、何时释放”。把所有权搞清楚，比记住 dispose(bool) 模板重要十倍。
