Task.Run与CancellationToken的取消机制解析：两类场景结果差异的原因探究

这个问题其实戳中了Task取消机制里一个很容易被忽略的细节，我来给你拆解清楚两种场景的核心差异：

场景1：任务状态为Canceled的真正原因 #

首先我得纠正一个小细节：你的场景1代码如果真的没给Task.Run传入token，那任务状态应该是RanToCompletion才对——毕竟lambda只是睡了5ms就正常结束了，没抛出任何异常。所以我推测你大概率是漏写了Task.Run的第二个参数（应该是Task.Run(() => {...}, token)），这才是任务进入Canceled状态的关键：

• 你给CancellationTokenSource设置了1ms超时，而线程池调度任务需要一点时间，再加上lambda里的Thread.Sleep(5)，导致Task还没开始执行lambda，对应的token就已经处于取消状态了。
• 当你把token传递给Task.Run时，Task框架会在调度前先检查token状态：如果token已经取消，任务会直接进入Canceled状态，连lambda里的代码都不会执行。这就是为什么你注释掉抛出异常的代码、甚至移除lambda里的Sleep，任务状态还是Canceled——因为任务从一开始就没被允许执行。

场景2：任务状态为Faulted的核心原因 #

这个场景的问题出在你没有把token传递给Task.Run：

你之前总结的三个取消条件是对的，但漏了一个隐含前提：抛出OperationCanceledException的任务，必须和这个token存在关联（也就是创建任务时传入了该token）。

当Task没有关联这个token时，哪怕你在lambda里抛出携带该token的OperationCanceledException，Task框架也会把这个异常当成普通的未处理异常，任务自然就进入Faulted状态了——对Task来说，这个异常和你抛出NullReferenceException没有本质区别，它根本不知道这是一个合法的取消请求。

关于你提到的if(true)替代判断的情况 #

如果你把场景2里的判断改成if(true)，不管token状态如何都抛出OperationCanceledException(token)：

• 只要Task.Run没传入token，任务状态永远是Faulted；
• 如果Task.Run传入了token，且此时token.IsCancellationRequested为true，任务会进入Canceled状态；
• 如果Task.Run传入了token，但token.IsCancellationRequested为false，任务还是会进入Faulted状态——因为这时候抛出OCE属于“无理由取消”，Task会认为是错误而非合法取消。

最后再明确Task进入Canceled状态的完整条件 #

结合你的总结，补充上关键前提后，完整条件是：

• 任务创建时必须传入对应的CancellationToken（比如Task.Run(action, token)）；
• 在任务执行过程中抛出OperationCanceledException，并将同一个CancellationToken传入其构造函数；
• 该CancellationToken的IsCancellationRequested属性值为true；
• （或者任务还未开始执行，就检测到token已取消）

这样就能完美解释你遇到的两种截然不同的任务状态了。

内容的提问来源于stack exchange，提问作者Игорь Гарбуз