实现 IAsyncDisposable 时必须 await 内部异步操作、使用 ConfigureAwait(false)、统一异步释放策略、确保幂等与线程安全，否则可能导致资源泄漏、死锁或异常。
实现 IAsyncDisposable 时必须 await DisposeAsync() 内部异步操作
如果你在 DisposeAsync() 中调用了其他异步资源释放方法（比如 stream.DisposeAsync()、httpClient.DisposeAsync()），不 await 它们会导致资源实际未释放，且可能抛出 ObjectDisposedException 或静默失败。C# 编译器不会强制你 await，但逻辑上这是销毁流程的一部分。
- 错误写法：
stream.DisposeAsync();（没 await，调度回原上下文前就返回了） - 正确写法：
await stream.DisposeAsync().ConfigureAwait(false); - 若内部有多个异步 dispose，建议按依赖顺序 await，避免并发 dispose 引发状态冲突
ConfigureAwait(false) 在 DisposeAsync() 中几乎总是必要
绝大多数 IAsyncDisposable 实现运行在非 UI 线程（如 ASP.NET Core 请求处理线程池、后台服务），不需要回到原始同步上下文。不加 ConfigureAwait(false) 可能导致死锁（尤其在旧版 ASP.NET 同步上下文未被禁用时），或带来不必要的上下文捕获开销。
- 例外场景极少：仅当你明确知道该类型会被 UI 线程（WPF/WinForms）直接持有并调用
DisposeAsync()，且后续清理逻辑依赖SynchronizationContext（比如更新 UI 控件）——但这种设计本身已违背异步资源管理原则 - ASP.NET Core 中默认无
SynchronizationContext，但显式加ConfigureAwait(false)是防御性编码习惯 - 注意：不是所有
DisposeAsync()调用点都可控；库使用者可能在任意上下文中 await，所以实现端应主动规避上下文依赖
不要在 DisposeAsync() 中混用同步和异步释放逻辑
常见反模式是：对一部分资源调用同步 Dispose()，另一部分调用 await DisposeAsync()。这会破坏异步契约的语义一致性，也容易漏掉可异步释放的资源（比如 MemoryStream 虽然 Dispose() 是空操作，但某些包装流可能不是）。
- 统一策略：优先走
IAsyncDisposable分支，即使底层实现是同步的（例如ValueTask.CompletedTask） - 避免 fallback 到
Dispose()：除非你 100% 确认该资源没有异步释放路径，且DisposeAsync()未被重写（可通过typeof(T).GetInterface("IAsyncDisposable") != null检查，但不推荐运行时判断） - 特别注意第三方库：有些类型只实现了
IDisposable，没实现IAsyncDisposable，此时不能强行 await —— 必须区分处理，否则编译不过或运行时报错
别忽略 DisposeAsync() 的幂等性和线程安全性
DisposeAsync() 可能被多次调用（比如用户代码重复 await），也可能被并发调用（如取消任务后又手动 dispose）。.NET 不保证该方法天然幂等或线程安全，需自行防护。
- 典型做法：用
private volatile bool _disposed;+Interlocked.CompareExchange或AsyncLock（如SemaphoreSlim）保护首次执行 - 注意：
ValueTask不能多次 await，所以返回前必须确保它只被构造一次；建议统一返回ValueTask.CompletedTask或缓存结果 - 如果内部有
CancellationTokenSource，应在首次 dispose 时.Cancel()并.Dispose()，后续调用直接返回完成 task
真正容易被忽略的是：很多开发者以为只要类实现了 IAsyncDisposable，调用方用 await using 就万事大吉。但实际中，dispose 逻辑是否真正异步、是否 await 了子资源、是否被并发触发、是否在错误上下文中执行——这些细节全由你实现时决定，编译器一个都不会帮你检查。
