必须同时实现 IDisposable 和 IAsyncDisposable，否则 using 或 DI 容器仅调用 Dispose() 会漏掉异步清理导致资源泄漏；DisposeAsync() 负责协调与线程安全，DisposeAsyncCore() 专注纯异步清理，且需注意释放顺序与并发安全。
必须同时实现 IDisposable 和 IAsyncDisposable，否则调用方只调用 Dispose() 就会漏掉异步清理逻辑，导致资源泄漏。
为什么单独实现 IAsyncDisposable 会出问题
常见错误是看到“异步释放”就只加 IAsyncDisposable，结果在 using 块或 DI 容器中被当作同步资源处理。.NET 的 using 语句（非 await using）和 IServiceProvider 默认只识别 IDisposable；如果类没实现它，DisposeAsync() 根本不会被触发。
- DI 容器销毁服务时，只检查
IDisposable，忽略IAsyncDisposable -
using (var x = new MyResource()) { ... }会调用Dispose()，但若你没实现该方法，编译都过不去；即使绕过（比如用object强转），实际也不会执行任何释放 - 终结器（finalizer）里通常只调用
Dispose(false)，而它不 awaitDisposeAsyncCore()，导致非托管资源可能被提前回收或重复释放
DisposeAsync() 和 DisposeAsyncCore() 怎么分工
标准模式是：公开的 DisposeAsync() 负责协调（如设置释放标记、抑制终结器），真正的异步清理逻辑放在受保护的 DisposeAsyncCore() 中。这样子类可重写 DisposeAsyncCore()，而基类控制执行时机和线程安全。
-
DisposeAsync()必须是public、async（或返回ValueTask）、无参数；它内部应调用DisposeAsyncCore()并await其结果 -
DisposeAsyncCore()应为protected virtual ValueTask，只做纯异步清理：关闭网络连接、清空异步缓冲区、等待后台任务完成等 - 同步清理（如释放文件句柄、取消
CancellationTokenSource）仍应放在Dispose(bool)里，由Dispose()和终结器共用
await using 的实际行为和限制
await using 不是 using 的“升级版”，而是独立语法糖，只对实现了 IAsyncDisposable 的类型生效。它生成的代码结构类似 try/finally，但 finally 块里是 await d.DisposeAsync()。
- 不能混用：
await using声明的对象，不能在同一个作用域内再用普通using包裹，否则编译报错 - 不支持多变量声明：
await using (var a = ..., var b = ...)是非法语法，必须拆成多个await using或嵌套 - 异常传播：如果
DisposeAsync()抛出异常，它会覆盖try块中已发生的异常（和同步using一样），需在业务逻辑里主动try/catch处理
最容易被忽略的释放顺序和线程安全
异步释放不是“把所有 await 拆开就行”。比如一个类既持有 Timer 又持有 HttpClient，DisposeAsyncCore() 里先 await httpClient.DisposeAsync() 再 timer.Dispose() 是错的——Timer 回调可能还在运行，此时 httpClient 已释放，回调里再用就会抛 ObjectDisposedException。
- 必须先停掉所有可能触发后续操作的组件（如
timer.Change(Timeout.Infinite, Timeout.Infinite)、取消CancellationTokenSource），再释放它们依赖的资源 -
_disposed标记要volatile或用Interlocked操作，防止多线程并发调用DisposeAsync()导致重复 await - 不要在
DisposeAsyncCore()里启动新线程或长期运行的Task.Run，这会让释放不可控；应使用await等待已有异步操作自然结束
