Task取消机制疑问：为何仅调用ThrowIfCancellationRequested才能触发OnlyOnCanceled延续任务？

这个问题其实是对.NET Task取消机制的常见误解——咱们一步步拆解清楚：

核心原因：Task的Canceled状态有严格判定条件 #

.NET中，一个Task要被标记为Canceled状态，必须满足两个关键条件：

• 任务抛出了OperationCanceledException异常
• 这个异常关联的CancellationToken正是触发取消请求的那一个

如果只是通过break跳出循环，你的ExecutePoll方法会正常执行完毕，Task的状态就会是RanToCompletion，自然不会触发指定了TaskContinuationOptions.OnlyOnCanceled的延续任务。

再看你代码里的几个细节 #

1. Task.Run的第二个令牌参数作用有限
   你在Task.Run时传入了_pollProcessTokenSource.Token，但这个参数仅在任务还没开始执行（仍在调度队列中）时生效：此时调用Cancel会直接取消任务的排队状态，让任务进入Canceled。但你的任务已经立刻启动执行了，所以这个参数在任务运行过程中完全不起作用。

2. ExecutePoll两种退出方式的本质差异

   • 用break：方法按正常流程走完并退出，Task顺利完成，状态为RanToCompletion，OnlyOnCanceled分支的延续任务不会被触发。
   • 用cancellationToken.ThrowIfCancellationRequested()：这个方法会抛出绑定当前令牌的OperationCanceledException，Task捕获到该异常后，会将自身状态标记为Canceled，此时OnlyOnCanceled的延续任务就会被执行。

几种正确的处理方式 #

方式一：遵循官方取消规范（推荐）

保留ThrowIfCancellationRequested()，这是.NET官方推荐的取消模式，语义清晰且符合Task的设计逻辑，还能让异步操作（比如Task.Delay）也响应取消：

private static async Task ExecutePoll(CancellationToken cancellationToken)
{
    while (true)
    {
        cancellationToken.ThrowIfCancellationRequested(); // 提前检查并抛出取消异常
        Console.WriteLine("Looping...");
        await Task.Delay(1000, cancellationToken); // 将令牌传给Delay，让Delay也能立刻响应取消
    }
}

方式二：手动标记任务为Canceled（适合不想抛异常的场景）

如果你确实不想抛出异常，可以手动返回一个已取消的Task，同样能让任务状态变为Canceled：

private static Task ExecutePoll(CancellationToken cancellationToken)
{
    while (true)
    {
        if (cancellationToken.IsCancellationRequested)
        {
            Console.WriteLine("Exit from poll loop!");
            // 手动返回已取消的Task实例
            return Task.FromCanceled(cancellationToken);
        }
        Console.WriteLine("Looping...");
        // 注意：这里如果用await，需要调整方法逻辑，示例简化处理
        Thread.Sleep(1000);
    }
}

不过这种方式不如抛出异常直观，官方更推荐前者。

总结 #

Task的Canceled状态不是由令牌是否被取消决定的，而是由任务是否因该令牌引发的取消异常而终止决定的。单纯跳出循环属于任务正常完成，自然不会触发取消相关的延续任务。

内容的提问来源于stack exchange，提问作者Felipe Correa