TaskCanceledException是协作式取消信号而非错误，应捕获OperationCanceledException并校验ct.IsCancellationRequested，避免静默吞异常；正确传递CancellationToken到底层API。
TaskCanceledException 是取消信号，不是错误
遇到 TaskCanceledException 时，第一反应不该是“出错了要捕获并吞掉”，而是确认：这个取消是否符合预期。它本质是 CancellationToken 正常触发的协作式中断结果，和 IOException 或 NullReferenceException 性质完全不同。强行 catch 后静默处理，反而会掩盖逻辑问题——比如本该响应取消却卡死在某个 I/O 操作上。
常见误操作包括：
- 在 async 方法里用 try/catch (TaskCanceledException) 包裹整个 await 调用，却不检查 cancellationToken.IsCancellationRequested
- 把 TaskCanceledException 和 OperationCanceledException 当作两个独立异常分别处理（其实前者是后者的子类）
- 在 ContinueWith 中忽略 TaskStatus.Canceled 状态，只靠异常捕获判断取消
正确捕获位置：await 之后、或 Task.Wait() 时
TaskCanceledException 只会在两种典型场景中抛出：
- 对已取消的 Task 调用 .Wait() 或访问 .Result / .Exception
- await 一个被取消的异步操作（此时实际抛出的是 OperationCanceledException，但调试器常显示为 TaskCanceledException）
因此，捕获点必须紧贴这些操作：
try
{
await DoWorkAsync(ct);
}
catch (OperationCanceledException) when (ct.IsCancellationRequested)
{
// ✅ 正确：明确知道是用户主动取消，可记录日志或清理
Log("任务被用户取消");
Cleanup();
}注意：
- 不要用 catch (TaskCanceledException)，应捕获基类 OperationCanceledException
- when (ct.IsCancellationRequested) 条件确保不是内部意外取消（如线程池枯竭）
- 若在非 await 上下文（如同步阻塞调用），才可能真正遇到 TaskCanceledException，此时需检查 task.Status == TaskStatus.Canceled
不要在 Task.Run 内部手动 throw new OperationCanceledException()
很多人想“主动触发取消”，于是写：Task.Run(() => { if (ct.IsCancellationRequested) throw new OperationCanceledException(ct); })。这完全多余——Task.Run 本身不响应 CancellationToken，传进去的 ct 不会被自动监听。
正确做法只有两种：
- 使用支持 CancellationToken 的 API，例如 Task.Delay(1000, ct)、stream.ReadAsync(buffer, ct)
- 在循环中手动轮询：while (!ct.IsCancellationRequested) { /* work */ }，并在退出前调用 ct.ThrowIfCancellationRequested()
- 若必须包装同步代码，用 Task.Run(() => { ct.ThrowIfCancellationRequested(); /* work */ }, ct) —— 注意第二个参数才是让 Task 关联取消令牌的关键
ConfigureAwait(false) 不影响取消异常行为
有人以为加了 ConfigureAwait(false) 就不会抛 OperationCanceledException，这是误解。取消机制完全由 CancellationTokenSource 和各异步方法内部实现决定，和上下文捕获无关。
真实影响只有一处：
- 若在 UI 线程调用 await task.ConfigureAwait(false)，且 task 被取消，异常仍会按原样抛出，只是不会尝试切回 UI 上下文
- 但异常类型、时机、是否可捕获，和是否配置 ConfigureAwait 完全无关
真正容易被忽略的是：在库函数中暴露 CancellationToken 参数时，必须传递到底层调用链，否则取消信号到不了真正耗时操作那里——哪怕你 catch 了异常，也只是在“取消已发生之后”做善后，而非“及时中止执行”。
