TaskCanceledException 和 OperationCanceledException 的关系是什么
它们不是两个独立的异常类型，而是有明确继承关系：
TaskCanceledException继承自
OperationCanceledException。这意味着捕获
OperationCanceledException就能同时覆盖两者，但反过来不行。
实际中绝大多数由
await一个被取消的
Task抛出的是
TaskCanceledException；而直接调用
cancellationToken.ThrowIfCancellationRequested()或某些同步取消路径抛出的是更基础的
OperationCanceledException。
常见错误现象：只 catch
TaskCanceledException，结果漏掉部分取消场景（比如底层库手动 throw 的
OperationCanceledException）。
应该在 await 后 catch 还是用 try-catch 包裹整个 async 方法体
必须把
try-catch放在
await所在的作用域内，而不是仅包裹
await表达式本身——因为
await可能触发多个异步点，且异常可能来自延续（continuation）阶段。
推荐结构：
async Task DoWorkAsync(CancellationToken cancellationToken)
{
try
{
await SomeAsyncOperation(cancellationToken);
await AnotherAsyncOperation(cancellationToken);
}
catch (OperationCanceledException)
{
// ✅ 正确：覆盖所有取消路径
Log("Operation was canceled");
throw; // 如果上层也要感知取消，建议 re-throw
}
}
不推荐写法：
var task = SomeAsyncOperation(ct); await task;+ 单独 try-catch task —— 多余且掩盖了 async 方法本身的取消传播逻辑 只 catch
TaskCanceledException—— 漏掉非 Task 包装的取消异常 在 catch 块里吞掉异常又不 re-throw —— 破坏调用链的取消信号，可能导致资源泄漏或状态不一致
如何区分“用户主动取消”和“异常中断”
不能单靠异常类型判断是否为“用户取消”，关键要看
OperationCanceledException.CancellationToken是否与你传入的 token 相同，且该 token 的
IsCancellationRequested为
true。
示例判断逻辑：
catch (OperationCanceledException ex)
{
if (ex.CancellationToken == cancellationToken && cancellationToken.IsCancellationRequested)
{
// ✅ 可信的用户取消
CleanupResources();
return;
}
else
{
// ⚠️ 异常来自其他 token 或状态异常，应重新 throw
throw;
}
}
注意点：
不要仅依赖ex.Message.Contains("cancelled") —— 消息可能本地化或被修改
不要忽略 ex.CancellationToken字段，它才是唯一权威来源 如果方法接收多个
CancellationToken（如组合 token），需确认具体是哪个被触发
ConfigureAwait(false) 对取消异常处理有影响吗
没有直接影响。取消异常的类型、抛出时机、堆栈信息都与
ConfigureAwait无关。但它会影响异常发生时的上下文（比如
SynchronizationContext或
TaskScheduler），进而影响异常是否能在预期线程被捕获（例如 UI 线程）。
典型问题场景：
WinForms/WPF 中，未用ConfigureAwait(false)的后台任务被取消，异常可能被封送到 UI 线程再抛出，导致意外的跨线程访问或死锁 ASP.NET Core 中，通常建议统一用
ConfigureAwait(false)，避免争用请求上下文，但取消异常仍会正常冒泡到
try-catch
所以重点不是“要不要加”，而是“加在哪”：在非 UI/非上下文敏感的底层 async 方法里加；在需要回到原始上下文的位置（如事件处理函数末尾）才不加。
取消本身不因
ConfigureAwait改变行为，但异常的传播路径和线程归属会变。
