ASP.NET Core中的过滤器是什么？如何应用？

ASP.NET Core中的过滤器，在我看来，它就是框架提供的一套精巧的“钩子”机制，允许你在HTTP请求生命周期的特定阶段插入自定义逻辑。简单来说，它们让你能在控制器动作执行前、后，或者结果生成前、后，甚至在发生异常时，运行一些代码。这极大地帮助我们处理那些横跨多个功能模块的“横切关注点”，比如日志记录、性能监控、授权验证、缓存处理，甚至是统一的错误响应。应用这些过滤器的方式也相当灵活，既可以在全局层面生效，也可以针对特定的控制器或单个动作进行配置，通常是通过特性（Attributes）或者依赖注入来完成。

解决方案

谈到ASP.NET Core的过滤器，我总是觉得它们是构建可维护、可扩展应用的基石之一。它们的核心价值在于将那些与核心业务逻辑无关但又必不可少的辅助功能，从业务代码中抽离出来，实现关注点分离。

ASP.NET Core的过滤器体系主要分为五种类型，它们按照执行顺序排列，各自负责不同的职责：

授权过滤器 (Authorization Filters)：这是最先执行的过滤器，用于确定用户是否有权访问某个资源。如果授权失败，请求会直接被短路，不会继续执行后续的过滤器或动作。最常见的例子就是

[Authorize]

特性。 资源过滤器 (Resource Filters)：在授权之后，模型绑定之前执行。它可以在模型绑定之前或之后运行代码，甚至可以短路整个请求管道，比如用于实现响应缓存，或者在某些条件下直接返回结果，避免后续不必要的计算。 动作过滤器 (Action Filters)：在控制器动作方法执行之前和之后运行代码。这对于日志记录、性能分析、输入验证（在模型绑定之后，动作执行之前）等场景非常有用。 异常过滤器 (Exception Filters)：当动作、动作过滤器、结果过滤器或结果执行过程中抛出未处理的异常时执行。它们提供了一个集中的地方来处理异常，可以记录错误、返回友好的错误响应等。 结果过滤器 (Result Filters)：在动作方法成功执行并生成结果之后，但在结果写入响应之前和之后运行。例如，你可以在这里修改响应头、压缩内容或者进行一些后处理。

如何应用过滤器？

应用过滤器的方式非常多样，这体现了ASP.NET Core的灵活性：

Program.cs

AddControllersWithViews

AddRazorPages

options.Filters.Add()

builder.Services.AddControllersWithViews(options =>
{
    options.Filters.Add(new MyGlobalActionFilter());
    options.Filters.Add(typeof(MyGlobalExceptionFilter)); // 可以是类型，让DI来创建
});

// 应用到整个控制器
[MyControllerLevelActionFilter]
public class HomeController : Controller
{
    // 应用到单个动作
    [MyActionLevelActionFilter]
    public IActionResult Index()
    {
        return View();
    }
}

[ServiceFilter]

[TypeFilter]

[ServiceFilter(typeof(MyDIActionFilter))]

MyDIActionFilter

[TypeFilter(typeof(MyDIActionFilter))]

MyDIActionFilter

MyDIActionFilter

// 注册过滤器到DI容器
builder.Services.AddScoped<MyDIActionFilter>();
// 在控制器或动作上使用
[ServiceFilter(typeof(MyDIActionFilter))]
public class ProductsController : Controller
{
    // ...
}

一个简单的动作过滤器示例，用于记录动作的执行时间：

public class LogActionPerformanceFilter : IActionFilter
{
    private readonly ILogger<LogActionPerformanceFilter> _logger;
    private Stopwatch _stopwatch;
    public LogActionPerformanceFilter(ILogger<LogActionPerformanceFilter> logger)
    {
        _logger = logger;
    }
    public void OnActionExecuting(ActionExecutingContext context)
    {
        _stopwatch = Stopwatch.StartNew();
        _logger.LogInformation($"Executing action {context.ActionDescriptor.DisplayName}...");
    }
    public void OnActionExecuted(ActionExecutedContext context)
    {
        _stopwatch.Stop();
        _logger.LogInformation($"Action {context.ActionDescriptor.DisplayName} executed in {_stopwatch.ElapsedMilliseconds}ms.");
        if (context.Exception != null)
        {
            _logger.LogError(context.Exception, $"Action {context.ActionDescriptor.DisplayName} threw an exception.");
        }
    }
}

要使用这个过滤器，你需要在

Program.cs

builder.Services.AddScoped<LogActionPerformanceFilter>();

[ServiceFilter(typeof(LogActionPerformanceFilter))]

ASP.NET Core过滤器：为何它们是解耦横切关注点的利器？

我个人觉得，过滤器在解耦横切关注点方面，简直是ASP.NET Core提供的一把瑞士军刀。在没有过滤器之前，我们可能会在每个控制器或动作方法中重复编写一些辅助逻辑，比如权限检查、日志记录或者数据验证。想想看，如果你的应用有几十个甚至上百个动作方法，每个方法里都散落着这些重复的代码，那维护起来简直是噩梦。一旦需求变更，比如日志格式要调整，你可能需要修改几十个地方，这不仅效率低下，还极易出错。

过滤器就完美解决了这个问题。它们提供了一种机制，让你能够将这些“横切”于核心业务逻辑之外的功能，集中到一个独立的地方进行管理。这就像是给你的业务逻辑穿上了一件“外套”，这件外套负责处理各种周边事务，而核心业务逻辑则可以专注于它自己的使命。

举个例子，假设你需要对所有需要管理员权限的API进行验证。没有过滤器，你可能需要在每个管理员API的开头都写一段

if (!User.IsInRole("Admin")) { return Forbid(); }

[Authorize(Roles = "Admin")]

很多人会把过滤器和中间件（Middleware）混淆。我的理解是，中间件处理的是整个HTTP请求管道的“宏观”流程，它在请求到达MVC/Razor Pages层之前就开始工作了，更适合处理全局性的请求/响应操作，比如静态文件服务、路由、身份认证等。而过滤器则是在MVC/Razor Pages管道内部，更“微观”地作用于控制器、动作、结果等特定阶段。你可以把中间件想象成高速公路上的关卡，而过滤器则是进入某个城市（MVC/Razor Pages）后，在特定建筑（控制器/动作）门口的安检或登记。它们各司其职，共同构成了ASP.NET Core强大的请求处理能力。这种清晰的分工，正是ASP.NET Core能够有效解耦复杂应用的关键所在。

如何在ASP.NET Core中创建自定义过滤器并有效管理其生命周期？

创建自定义过滤器其实并不复杂，但要用好它，理解其生命周期和依赖注入（DI）机制至关重要。

要创建一个自定义过滤器，你需要实现ASP.NET Core提供的相应接口。例如，如果你想在动作执行前后做些事情，就实现

IActionFilter

IAsyncActionFilter

OnActionExecuting

OnActionExecuted

OnActionExecutionAsync

ActionExecutingContext

ActionExecutionDelegate

await next()

// 异步动作过滤器示例
public class CustomAsyncActionFilter : IAsyncActionFilter
{
    private readonly ILogger<CustomAsyncActionFilter> _logger;
    public CustomAsyncActionFilter(ILogger<CustomAsyncActionFilter> logger)
    {
        _logger = logger;
    }
    public async Task OnActionExecutionAsync(ActionExecutingContext context, ActionExecutionDelegate next)
    {
        _logger.LogInformation($"Before action {context.ActionDescriptor.DisplayName} execution.");
        // 在这里可以修改 context.Result 来短路请求
        // context.Result = new BadRequestObjectResult("Invalid input");
        // 调用下一个过滤器或动作方法
        var resultContext = await next();
        _logger.LogInformation($"After action {resultContext.ActionDescriptor.DisplayName} execution. Status: {resultContext.Result?.GetType().Name}");
        if (resultContext.Exception != null && !resultContext.ExceptionHandled)
        {
            _logger.LogError(resultContext.Exception, $"Action {resultContext.ActionDescriptor.DisplayName} threw an unhandled exception.");
        }
    }
}

管理生命周期和依赖注入

过滤器实例的生命周期与它们如何被注册和使用密切相关。

Program.cs

AddScoped

AddTransient

LogActionPerformanceFilter

Stopwatch

[ServiceFilter]

[TypeFilter]

这俩特性虽然都能实现DI，但用法和适用场景略有不同，有时候确实让人有点困惑：

[ServiceFilter(typeof(MyFilter))]

MyFilter

Program.cs

builder.Services.Add*<MyFilter>()

MyFilter

[TypeFilter(typeof(MyFilter))]

MyFilter

[TypeFilter]

MyFilter

Arguments

我通常会倾向于使用

[ServiceFilter]

[TypeFilter]

ASP.NET Core过滤器在处理异常和提升安全性方面有哪些最佳实践？

在构建健壮的Web应用时，异常处理和安全性是两个无论如何都绕不开的核心议题。ASP.NET Core的过滤器在这两个领域都扮演着至关重要的角色，而且有一些实践心得值得分享。

异常过滤器：构建统一的错误响应

我发现，

IExceptionFilter

try-catch

最佳实践：

try-catch

ExceptionFilter

ArgumentNullException

400 Bad Request

ExceptionContext.Exception

IExceptionFilter

UseExceptionHandler

UseExceptionHandler

IExceptionFilter

// 简化版全局异常过滤器
public class GlobalExceptionFilter : IExceptionFilter
{
    private readonly ILogger<GlobalExceptionFilter> _logger;
    private readonly IHostEnvironment _env;
    public GlobalExceptionFilter(ILogger<GlobalExceptionFilter> logger, IHostEnvironment env)
    {
        _logger = logger;
        _env = env;
    }
    public void OnException(ExceptionContext context)
    {
        _logger.LogError(new EventId(context.Exception.HResult),
            context.Exception,
            context.Exception.Message);
        // 返回统一的错误响应
        var problemDetails = new ProblemDetails
        {
            Status = StatusCodes.Status500InternalServerError,
            Title = "An unexpected error occurred!",
            Type = "https://tools.ietf.org/html/rfc7807#section-3.1",
            Detail = _env.IsDevelopment() ? context.Exception.StackTrace : "Please try again later."
        };
        if (context.Exception is ArgumentException || context.Exception is FormatException)
        {
            problemDetails.Status = StatusCodes.Status400BadRequest;
            problemDetails.Title = "Invalid request data.";
            problemDetails.Detail = _env.IsDevelopment() ? context.Exception.Message : "The request data is invalid.";
        }
        // 更多自定义异常处理...
        context.Result = new ObjectResult(problemDetails)
        {
            StatusCode = problemDetails.Status
        };
        context.ExceptionHandled = true; // 标记异常已处理，阻止其继续传播
    }
}

授权过滤器：强化访问控制

授权过滤器是确保只有具备适当权限的用户才能访问特定资源的基石。

[Authorize]

最佳实践：

[Authorize]

Program.cs

[Authorize("MyCustomPolicy")]

IAuthorizationFilter

IAsyncAuthorizationFilter

总的来说，过滤器为我们提供了一个强大而灵活的工具箱，去应对应用开发中那些重复性高、但又至关重要的横切关注点。合理地利用它们，能让你的ASP.NET Core应用更安全、更易维护，也更具扩展性。