ASP.NET Core如何全局抑制用户关闭网页触发的TaskCanceledException

客户端提前关闭页面/断开连接触发的TaskCanceledException是ASP.NET Core 3.1/6的高频场景，本质是请求绑定的HttpContext.RequestAborted取消令牌被触发，不属于系统错误，不需要逐接口加try-catch，全局统一处理即可。

方案1：自定义异常中间件（推荐，覆盖全链路） #

这个方案可以覆盖从中间件到控制器、服务层全链路抛出的取消异常，是最稳妥的实现方式。注意不要无差别吞所有取消异常，只处理客户端主动断开触发的场景，避免掩盖业务超时、内部逻辑取消等真实故障。

首先实现中间件：

public class ClientDisconnectExceptionMiddleware
{
    private readonly RequestDelegate _next;
    private readonly ILogger<ClientDisconnectExceptionMiddleware> _logger;

    public ClientDisconnectExceptionMiddleware(RequestDelegate next, ILogger<ClientDisconnectExceptionMiddleware> logger)
    {
        _next = next;
        _logger = logger;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        try
        {
            await _next(context);
        }
        catch (OperationCanceledException) when (context.RequestAborted.IsCancellationRequested)
        {
            // 客户端主动断开场景，记录信息级日志即可，不按错误处理
            _logger.LogInformation("请求 {TraceId} 已取消，原因：客户端主动断开连接", context.TraceIdentifier);
            // 标记状态码即可，不要向响应体写内容，客户端已断开会触发二次异常
            context.Response.StatusCode = StatusCodes.Status499ClientClosedRequest;
            return;
        }
    }
}

注册中间件时，必须放在所有异常处理相关中间件的最前面，确保能在默认异常日志中间件捕获到异常之前就处理掉：

// .NET 6+ Program.cs
var app = builder.Build();
// 最先注册客户端断开异常处理中间件
app.UseMiddleware<ClientDisconnectExceptionMiddleware>();
// 之后再注册开发异常页、全局异常处理等其他中间件
if (app.Environment.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
}
else
{
    app.UseExceptionHandler("/Home/Error");
}
// 其他业务中间件、路由、授权中间件按原有顺序注册即可

方案2：全局异常过滤器（仅覆盖MVC/API控制器链路） #

如果你的项目所有接口逻辑都在控制器内执行，没有中间件层的长耗时逻辑，也可以用全局异常过滤器实现，代码更简单，但覆盖范围不如中间件全：

public class ClientDisconnectExceptionFilter : IExceptionFilter
{
    private readonly ILogger<ClientDisconnectExceptionFilter> _logger;

    public ClientDisconnectExceptionFilter(ILogger<ClientDisconnectExceptionFilter> logger)
    {
        _logger = logger;
    }

    public void OnException(ExceptionContext context)
    {
        if (context.Exception is OperationCanceledException && context.HttpContext.RequestAborted.IsCancellationRequested)
        {
            _logger.LogInformation("接口 {RequestPath} 请求已取消，原因：客户端主动断开", context.HttpContext.Request.Path);
            context.ExceptionHandled = true;
            context.Result = new StatusCodeResult(StatusCodes.Status499ClientClosedRequest);
        }
    }
}

注册过滤器：

// .NET 6+ Program.cs 注册控制器服务时添加
builder.Services.AddControllers(options =>
{
    options.Filters.Add<ClientDisconnectExceptionFilter>();
});

• 严格区分取消异常来源：必须加context.RequestAborted.IsCancellationRequested判断条件，只处理客户端主动断开触发的取消。业务超时、内部CancellationTokenSource主动取消、第三方服务调用超时触发的取消异常不能吞，否则会掩盖真实故障。
• 合理设置日志级别：客户端主动断开是正常用户行为，打Information或Debug级日志满足链路排查即可，不要打Error级别污染错误日志，干扰线上问题排查。
• 长耗时逻辑主动绑定取消令牌：长耗时的数据库查询、远程调用、循环计算逻辑要主动传入HttpContext.RequestAborted令牌，在客户端断开后及时终止执行，避免无意义的服务器资源消耗。比如EF Core默认会自动绑定请求取消令牌，自定义逻辑需要手动传递或判断令牌状态。
• 不要给已断开的客户端返回响应内容：客户端关闭连接后，向响应体写入内容会触发新的Socket异常，只要设置状态码、标记异常已处理即可。
• 不推荐直接用日志规则过滤：虽然可以通过Serilog、NLog的日志过滤规则屏蔽这类异常的Error日志，但可控性差，容易误过滤掉非客户端断开导致的取消异常，优先选择中间件主动处理的方案。

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