为什么 CancellationToken 不能直接取消 IAsyncDisposable.DisposeAsync()
因为
IAsyncDisposable.DisposeAsync()本身不接收
CancellationToken参数——它的签名固定为
ValueTask DisposeAsync()。你无法像
HttpClient.GetAsync(uri, cancellationToken)那样传入 token 来中断释放逻辑。这意味着：如果
DisposeAsync()内部执行了耗时的异步清理（比如等待远端服务确认断连、刷盘、关闭长连接），它不会响应外部取消请求。
在 DisposeAsync 中手动检查 CancellationToken 的正确姿势
必须把
CancellationToken持有为字段或闭包变量，并在
DisposeAsync()实现里显式轮询或传递给可取消的子操作。常见错误是只在构造时捕获 token，却没在释放路径中使用它。 把
CancellationToken存为私有只读字段（如
private readonly CancellationToken _ct;），构造时传入并保存 在
DisposeAsync()中优先检查
_ct.IsCancellationRequested，快速返回 将
_ct传给所有支持 cancel 的子调用，例如
stream.WriteAsync(buffer, _ct)、
semaphore.WaitAsync(_ct)避免在
DisposeAsync()中启动新
Task.Run或忽略 token 的阻塞调用（如
Thread.Sleep、无 token 版
Wait()）
public class ResilientResource : IAsyncDisposable
{
private readonly CancellationTokenSource _cts;
private readonly Stream _stream;
public ResilientResource(Stream stream, CancellationToken ct = default)
{
_stream = stream;
_cts = CancellationTokenSource.CreateLinkedTokenSource(ct);
}
public async ValueTask DisposeAsync()
{
if (_cts.Token.IsCancellationRequested)
return;
try
{
await _stream.FlushAsync(_cts.Token).ConfigureAwait(false);
await _stream.DisposeAsync().ConfigureAwait(false);
}
catch (OperationCanceledException) when (_cts.Token.IsCancellationRequested)
{
// 预期行为：子操作因 token 被取消，静默处理
}
finally
{
_cts.Dispose();
}
}
}
结合 using await 和 CancellationToken 的实际调用方式
调用方必须确保
CancellationToken在整个生命周期内有效，且不能在
using await块外提前触发
Cancel()，否则
DisposeAsync()可能刚进入就立即退出，导致资源未清理。 不要用
var cts = new CancellationTokenSource(); cts.Cancel(); using await ...—— token 已失效 推荐在 async 方法内统一管理：用
using var cts = new CancellationTokenSource(timeoutMs);，再传入构造函数和后续逻辑
using await语句本身不接受 token，取消只能靠资源内部响应，所以依赖上面的手动检查机制 若需“强制超时取消 DisposeAsync”，得在外层套一层
WaitAsync(ct)包装，但要注意这会丢失原生
ValueTask性能优势
await using var resource = new ResilientResource(stream, cts.Token); await DoWorkAsync(resource, cts.Token); // 此处 cts.Cancel() 触发后，resource.DisposeAsync() 内部会响应
容易被忽略的线程安全与状态竞争点
DisposeAsync()可能被多次调用（尤其在异常路径或并发场景下），而
CancellationToken的检查和清理逻辑若没加锁或状态标记，会导致重复释放、NullReference 或竞态取消。 添加私有
private volatile bool _disposed;字段，首次进入时设为
true，后续直接 return 不要在
DisposeAsync()中修改共享状态后再检查
IsCancellationRequested—— 顺序错乱会导致漏响应
CancellationToken.Register()是危险操作：注册的回调可能在 token 已取消后仍执行，且难以控制执行上下文；优先用
ThrowIfCancellationRequested()或
WaitAsync(ct)如果底层资源（如
NetworkStream）本身不支持 cancel on dispose，强行注入 token 也无效——得换更底层可控的实现 CancellationToken 和 IAsyncDisposable 的结合不是自动生效的魔法，关键在于你是否在 DisposeAsync 的每一行清理代码里，都把它当作一个需要主动倾听的信号。
