CancellationToken行为疑惑：两种取消场景的异常表现为何不同？

现象回顾 #

• 无控制台异常场景（外部传入Token）
  代码：

  public async Task<List<UserDto>> GetAllUsers(CancellationToken cancellationToken)
  {   
      await Task.Delay(2000, cancellationToken);
      // ... 其他逻辑
  }
  

  通过Postman取消请求时，任务正常取消，控制台无异常输出，但用try-catch包裹await语句可捕获到TaskCanceledException。

• 控制台抛出异常场景（手动创建Token）
  代码：

  public async Task<List<UserDto>> GetAllUsers(CancellationToken cancellationToken)
  {
      CancellationTokenSource source = new CancellationTokenSource();
      CancellationToken token = source.Token;
      source.Cancel();
      
      await Task.Delay(2000, token);
      // ... 其他逻辑
  }
  

  执行后控制台直接输出：

  System.Threading.Tasks.TaskCanceledException: A task was canceled.

核心原因：上层调用栈的异常处理逻辑差异 #

1. 外部传入Token的请求取消场景
   这个Token通常由Web框架（如ASP.NET Core）生成并传入方法。当客户端（Postman）主动取消请求时，框架会自动捕获异步方法中抛出的TaskCanceledException，将其转化为对应的HTTP状态（比如499客户端关闭连接），不会让异常冒泡到控制台输出。
   这是因为请求取消属于正常的客户端行为，并非应用程序错误，框架会统一处理这类异常，避免控制台被无关信息干扰。

2. 手动创建Token的场景
   手动创建的CancellationTokenSource没有上层框架的异常处理逻辑兜底。当Task.Delay抛出TaskCanceledException后，异常会沿着调用栈向上传播，直到没有try-catch块捕获它，最终被.NET的全局未处理异常捕获机制处理，从而在控制台打印出异常信息。

验证方式 #

• 在外部传入Token的场景中，给await Task.Delay添加try-catch块，可以成功捕获到TaskCanceledException，证明异常确实存在，只是被上层框架处理了。
• 在手动创建Token的场景中，给await Task.Delay添加try-catch块，控制台也不会再打印异常，和外部传入的场景表现一致。

内容的提问来源于stack exchange，提问作者Daniil Kozenko