DbContext注册为Scoped服务时请求取消引发异常的问题

核心原因 #

你遇到的TaskCanceledException本质是用户主动终止请求导致的：按住F5频繁刷新页面时，浏览器会不断发起新请求，同时取消之前未完成的旧请求。而你代码中正确传递了HttpContext.RequestAborted这个CancellationToken，EF Core的异步操作会响应这个取消信号，抛出该异常——这属于正常的预期行为，并非程序bug。

解决方案 #

1. 捕获并合理处理取消异常 #

在请求处理的顶层（比如全局异常过滤器、控制器基类）捕获TaskCanceledException，无需将其视为错误记录或返回给前端，因为这是用户主动操作的结果：

public class GlobalExceptionHandler : IExceptionHandler
{
    private readonly ILogger<GlobalExceptionHandler> _logger;

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

    public async ValueTask<bool> TryHandleAsync(HttpContext httpContext, Exception exception, CancellationToken cancellationToken)
    {
        if (exception is TaskCanceledException)
        {
            // 记录温和日志，避免错误日志泛滥
            _logger.LogInformation("Request was canceled by the user.");
            httpContext.Response.StatusCode = StatusCodes.Status499ClientClosedRequest;
            await httpContext.Response.WriteAsync("Request canceled.", cancellationToken);
            return true;
        }

        // 处理其他异常
        return false;
    }
}

记得在DI中注册这个全局异常处理器：

builder.Services.AddExceptionHandler<GlobalExceptionHandler>();
builder.Services.AddProblemDetails();

2. 恢复DbContext的Scoped生命周期 #

Transient生命周期不适合DbContext：EF Core设计时就推荐Scoped，因为每个DbContext实例会管理自己的连接状态，Transient会导致大量DbContext实例被创建，加重数据库连接池的负担，甚至引发连接耗尽问题。你之前改Transient后操作能完成只是巧合，并非正确解决方式。

3. 检查同步Attach操作的影响 #

虽然只有一次同步Attach调用，但如果该操作涉及大量实体或复杂关系，可能会短暂阻塞请求处理线程。可以考虑：

• 确保Attach仅针对单个实体，避免批量操作
• 如果EF Core版本支持，尝试使用异步版本的相关操作（比如AttachAsync，注意EF Core中部分操作没有异步重载，这种情况下同步调用是可接受的）

额外说明 #

频繁刷新时的请求取消是web应用中的常见场景，传递RequestAborted的CancellationToken是正确的做法——它能及时终止不必要的数据库操作，避免资源浪费。异常本身不是问题，问题在于未对这种预期异常进行处理，导致日志泛滥或错误提示给用户。

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