C#的OperationCanceledException是什么？如何处理取消请求？

在C#的异步编程模型中，OperationCanceledException是专门用于表达“操作被取消”这一语义的系统异常。它继承自System.OperationCanceledException，并关联一个CancellationToken对象。当代码通过取消令牌感知到取消请求，并主动抛出该异常时，调用链就能明确区分“任务失败”和“任务被中止”这两种完全不同的结果。这种设计让上层逻辑可以采取不同策略，比如取消时不记录错误日志，只释放资源。

一、OperationCanceledException的本质

OperationCanceledException位于System命名空间下，它的核心属性是CancellationToken，通过该属性可以拿到触发取消的令牌。与一般的Exception不同，它在语义上并不表示程序错误，而是协作式取消的结果。.NET中的很多基础库（如HttpClient、Task.Run、Channel等）在检测到令牌取消后，都会抛出这个异常或者它的子类TaskCanceledException。

从底层原理看，C#并没有强制中断线程的能力，取消完全依赖“协作”：任务内部需要周期性地检查CancellationToken.IsCancellationRequested，或者调用ThrowIfCancellationRequested方法。只有任务自己决定停下来并抛出异常，取消才算真正生效。这种方式避免了Thread.Abort带来的资源不安全的问题，也让取消过程可控。

1.1 构造与常见来源

最常见的触发方式是使用CancellationToken.ThrowIfCancellationRequested，它会在令牌已取消时抛出OperationCanceledException。另一种来源是await一个已经取消的Task，运行时会将底层取消包装为该异常。下面的代码展示了主动检查并抛出异常的基本形式：

using System;
using System.Threading;
using System.Threading.Tasks;

class Demo
{
    static async Task WorkAsync(CancellationToken token)
    {
        for (int i = 0; i < 10; i++)
        {
            // 若令牌取消，这里会抛出OperationCanceledException
            token.ThrowIfCancellationRequested();
            await Task.Delay(500, token);
            Console.WriteLine("进度：" + i);
        }
    }

    static async Task Main()
    {
        var cts = new CancellationTokenSource();
        // 模拟1秒后取消
        cts.CancelAfter(1000);
        try
        {
            await WorkAsync(cts.Token);
        }
        catch (OperationCanceledException)
        {
            Console.WriteLine("任务被取消了");
        }
    }
}

上面的示例中，Task.Delay本身也接收令牌，在延迟期间若取消会直接抛异常；而ThrowIfCancellationRequested则用于循环逻辑中的手动检查。两者结合能覆盖大多数异步场景。注意，捕获时应优先捕获具体的OperationCanceledException，而不是笼统的Exception，否则可能掩盖真正的错误。

二、如何处理取消请求

处理取消请求的核心思路是：在任务内部积极响应令牌，在调用方正确捕获异常并区分取消与失败。良好的结构可以显著降低维护成本，也让系统具备更好的弹性。例如Web接口在客户端断开连接时，ASP.NET Core会自动取消请求令牌，业务代码若忽略这一点，可能会继续做无用的重计算。

实践中我们通常将CancellationToken沿着调用栈向下传递，从控制器到服务再到数据访问层。这样任何一层都能在合适时机中止工作。同时，使用CancellationTokenSource可以组合多个取消条件，比如用户手动停止、整体超时、程序关闭等，非常灵活。

2.1 使用CancellationTokenSource管理取消

CancellationTokenSource负责发出取消信号，它的Token属性交给任务使用。我们可以通过CancelAfter实现超时取消，也能通过CreateLinkedTokenSource把多个令牌合并。以下示例演示了超时与手动取消的联动：

using System;
using System.Threading;
using System.Threading.Tasks;

class CancelManage
{
    static async Task ProcessAsync(CancellationToken token)
    {
        try
        {
            await Task.Delay(3000, token);
            Console.WriteLine("处理完成");
        }
        catch (OperationCanceledException)
        {
            Console.WriteLine("处理中途被取消");
        }
    }

    static async Task Run()
    {
        using var cts = new CancellationTokenSource();
        // 2秒后自动取消
        cts.CancelAfter(2000);

        // 也可在别处调用 cts.Cancel() 手动取消
        await ProcessAsync(cts.Token);
    }

    static async Task Main() => await Run();
}

在这个例子里，Task.Delay的令牌一旦取消会抛出OperationCanceledException，我们在方法内部捕获并输出日志，调用方无需重复处理。如果希望调用方统一处理，也可以不捕获，直接让异常冒泡，但要在最外层明确判断是不是取消异常，以免监控系统误报。

2.2 在ASP.NET Core中接收请求取消

在Web应用中，HttpContext.RequestAborted就是一个CancellationToken。当浏览器关闭或客户端断开，令牌会被取消。把该令牌传入业务方法，就能及时停止数据库查询或外部调用，节约服务器资源。示例代码如下：

using Microsoft.AspNetCore.Mvc;
using System.Threading;
using System.Threading.Tasks;

[ApiController]
[Route("api/work")]
public class WorkController : ControllerBase
{
    [HttpGet]
    public async Task<string> GetAsync(CancellationToken token)
    {
        // 模拟耗时查询，客户端断开时会抛出OperationCanceledException
        await Task.Delay(5000, token);
        return "done";
    }
}

如果不在Action中使用token，客户端断开后后台仍可能继续跑完逻辑。而传入令牌后，框架会在取消时抛出OperationCanceledException，ASP.NET Core默认会将其转换为499状态码，不会记为服务器错误。这对高并发接口尤其重要。

三、常见误区与最佳实践

很多开发者在捕获异常时分不清OperationCanceledException和TaskCanceledException的关系。其实TaskCanceledException是前者子类，专门表示Task被取消。捕获OperationCanceledException可以同时覆盖两者，但若需要针对Task做特殊处理，也可以分别捕获。另一个误区是认为取消会自动释放所有资源，实际上文件句柄、网络连接等仍需借助using或手动清理。

建议始终将CancellationToken作为参数显式传递，而不是用静态全局变量；在长时间循环、IO等待、重试逻辑中都插入取消检查；并且在日志中标记“取消”而非“错误”。这样运维系统能准确统计主动取消率，帮助评估前端体验与接口稳定性。

3.1 避免吞掉取消异常

有些代码为了“安静退出”会写catch(Exception){}，这会让取消异常也被吞掉，导致调用方无法感知任务状态。正确做法是至少捕获OperationCanceledException并做轻量处理，其余异常再按失败流程上报。下面是一段反面与正面对比：

using System;
using System.Threading;
using System.Threading.Tasks;

class Trap
{
    // 反面：吞掉所有异常，包括取消
    static async Task Bad(CancellationToken token)
    {
        try
        {
            await Task.Delay(2000, token);
        }
        catch (Exception)
        {
            // 什么都不做，调用方以为成功
        }
    }

    // 正面：区分取消与其他异常
    static async Task Good(CancellationToken token)
    {
        try
        {
            await Task.Delay(2000, token);
        }
        catch (OperationCanceledException)
        {
            Console.WriteLine("已取消，正常退出");
            throw; // 或根据业务决定是否向上抛
        }
    }
}

通过上面的对比可以看到，Good方法明确识别取消语义，让上层能依据是否发生OperationCanceledException来决定后续动作。对于后台服务，还可以结合IHostApplicationLifetime，在关机时取消所有令牌，保证优雅退出。

3.2 取消与事务的结合

在数据库事务中，如果操作被取消，应回滚事务而不是提交。多数ORM（如EF Core）在SaveChangesAsync传入令牌取消时会抛OperationCanceledException，此时事务自动回滚。但若使用了非托管连接，需要自己在catch中调用Rollback。示例如下：

using System;
using System.Data;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Data.SqlClient;

class TxDemo
{
    static async Task SaveAsync(CancellationToken token)
    {
        using var conn = new SqlConnection("Server=.;Database=test;Trusted_Connection=true");
        await conn.OpenAsync(token);
        using var tx = conn.BeginTransaction();
        try
        {
            var cmd = new SqlCommand("INSERT INTO Log VALUES(1)", conn, tx);
            await cmd.ExecuteNonQueryAsync(token);
            tx.Commit();
        }
        catch (OperationCanceledException)
        {
            tx.Rollback();
            Console.WriteLine("事务已回滚");
            throw;
        }
    }
}

这段代码在捕获到取消异常后显式回滚，避免脏数据。虽然现代驱动通常会在取消时自动清理连接状态，但显式控制能提升代码可读性与可靠性，也方便在分布式事务中做补偿。

四、总结

OperationCanceledException不是错误，而是C#协作取消机制的正式信号。掌握它的来源、捕获方式以及与CancellationToken的配合使用，是编写响应式、资源友好型系统的关键。从异步循环到Web请求，再到数据库事务，都应将取消视为一等公民。只有让每一层都尊重取消令牌，系统才能在用户离开、超时或维护关机时平稳停下，而不是盲目消耗算力。

OperationCanceledExceptionCancellationToken异步取消修改时间：2026-08-06 19:21:47