异步延续的取消确认机制解析及相关疑问

你的代码里同步任务的IsCanceled为false，异步任务的IsCanceled为true，这种差异本质是普通任务与异步状态机生成任务的取消逻辑不同导致的。

1. 普通任务的取消规则（如Task.Run创建的任务） #

Task.Run这类方式创建的普通任务，严格遵循文档规则：只有当抛出的OperationCanceledException携带的CancellationToken，与任务创建时传入的取消令牌（未传入则为CancellationToken.None）完全匹配时，任务才会被标记为Canceled。

在TestCancelSync方法中：

• Task.Run未传入任何取消令牌，任务关联的令牌是CancellationToken.None
• 方法内部创建的cts.Token是独立的全新令牌，抛出的OCE携带该令牌，和任务关联的None不匹配
• 因此任务会被标记为Faulted而非Canceled，IsCanceled返回false

2. 异步方法任务的取消规则（async/await生成的任务） #

由async方法返回的任务，行为由编译器生成的状态机控制，逻辑和普通任务不同：只要异步方法内部未被捕获的OperationCanceledException传播到状态机，任务就会被标记为Canceled，无论异常携带的令牌是否与任务关联的令牌一致。

在TestCancelAsync方法中：

• await Task.Yield()触发状态机调度，方法进入异步执行流程
• 内部创建的cts取消后抛出的OCE，会被状态机直接捕获并标记任务为Canceled，无需匹配任务创建时的令牌（此处任务关联令牌同样是CancellationToken.None）
• 因此IsCanceled返回true

你的问题解答 #

何时需要针对特定令牌确认取消？ #

• 普通任务：必须保证抛出的OCE令牌与任务创建时传入的令牌一致，才能让任务被正确标记为Canceled。如果令牌不匹配，异常会被视为普通错误，任务状态为Faulted。
• 异步方法任务：不需要严格匹配令牌，只要抛出未被捕获的OCE，任务就会被标记为Canceled。但最佳实践还是使用方法参数传入的取消令牌抛出异常，这样能和外部取消逻辑协同，符合调用者预期。

是否可以信任异步方法返回的所有任务都具备这种行为？ #

可以信任。这是.NET自引入async/await以来就保持的标准实现逻辑，属于既定行为（虽文档未专门强调）。唯一需要注意：如果异步方法内部捕获OCE并重新抛出其他异常，任务状态会变为Faulted；只有当OCE未被拦截、直接传播到状态机时，任务才会被标记为Canceled。

内容的提问来源于stack exchange，提问作者Kyle McClellan