调用 IDisposable.Dispose() 后再访问对象成员通常抛 ObjectDisposedException，但具体取决于实现：有的立即检查并抛出，有的延迟到操作资源时才崩溃。
Dispose后访问对象会抛什么异常
调用 IDisposable.Dispose() 后再访问对象成员，绝大多数情况下不会立即崩溃，但行为不可靠——因为资源（如文件句柄、数据库连接、非托管内存）已被释放，后续操作大概率触发 ObjectDisposedException。这个异常不是“一定立刻抛”，而是取决于具体实现：有些类在属性/方法开头主动检查 _disposed 标志并手动抛出；有些则等到真正操作底层资源时才崩（比如读已关闭的 FileStream 会抛 IOException，而非 ObjectDisposedException）。
常见错误现象：
- 调试时看似正常，发布后偶发崩溃
- 在
using块外继续使用变量，IDE 不报错，运行时报ObjectDisposedException: Cannot access a disposed object. - 多线程下，一个线程刚
Dispose()，另一个线程同时调用Write()，结果不确定
怎么安全判断一个对象是否已被释放
C# 没有统一的 IsDisposed 属性或标准接口方法。是否可查，完全取决于类型作者是否公开了该状态。你只能看文档或源码，不能假设所有 IDisposable 类型都支持判断。
实操建议：
- 优先依赖约定：遵守
using语句或try/finally，而不是事后检查 - 对已知公开状态的类型，直接读取对应字段/属性，例如：
stream.CanRead在Dispose()后返回false；timer.Enabled可能仍为true，但实际不工作——不能依赖它判断是否释放 - 自定义类型中若需暴露状态，应显式添加
bool IsDisposed { get; }并在Dispose()中设为true，且加锁保护（多线程场景） - 不要用
try/catch (ObjectDisposedException)来“探测”是否释放——这是反模式，性能差且掩盖设计问题
Dispose() 被多次调用会怎样
按 .NET 官方设计规范，Dispose(bool) 模式必须支持幂等：重复调用 Dispose() 应静默成功，不抛异常、不重复释放资源。但现实是，大量第三方库或老代码没遵守这点。
实操建议：
- 自己写
Dispose()时，务必用私有字段（如private bool _disposed = false;）做守卫，并在入口处加if (_disposed) return; - 调用别人写的
Dispose()前，不要自己加判空或重复检查——既没必要，也可能引入竞态（比如两次检查之间已被释放） - 若遇到某类型重复
Dispose()抛异常（如InvalidOperationException: Safe handle has been closed），说明它不符合规范，应视为 bug 上报，或绕过（如确保只 dispose 一次）
async 场景下 Dispose 的坑
IDisposable 是同步接口，而现代 C# 大量使用异步 I/O（如 HttpClient、Stream 子类）。直接在 await 后调用 Dispose() 是危险的：异步操作可能仍在后台运行，此时释放会导致未定义行为（连接中断、数据截断、内存损坏）。
实操建议：
- 优先使用
IAsyncDisposable（.NET 5+）和await using语法，例如：await using var client = new HttpClient(); - 对只实现
IDisposable的类型（如旧版SqlConnection），确保所有异步操作完成后再Dispose()，即await task; obj.Dispose();，而不是obj.Dispose(); await task; - 不要在
async void或终结器里调用Dispose()—— 异步操作无法被等待，资源释放时机失控
最常被忽略的一点：Dispose() 本身不解决生命周期管理问题，它只是清理工具。真正关键的是谁拥有对象、何时创建、何时决定它“不再需要”。把 Dispose 当成“防崩补丁”，往往意味着对象作用域设计已经出错了。
