自定义ActionFilter属性相较于RequestSizeLimit属性性能低下问题排查与优化咨询

问题根源：ActionFilter的执行时机太晚了 #

你的推测完全正确——自定义ActionFilterAttribute的性能问题，核心在于它执行的时机太晚，已经在请求体被完整读取到内存之后才进行校验。而原生的[RequestSizeLimit]是在ASP.NET Core管道的极早期就介入，直接拦截过大的请求，根本不会读取整个请求体，这就是两者性能差异的关键。

具体原因拆解：

• 原生RequestSizeLimit的工作原理：它实现了IRequestSizeLimitMetadata接口，ASP.NET Core的底层管道（比如BodyReaderMiddleware）会在读取请求体之前检查这个元数据，如果请求大小超过限制，直接返回413 Payload Too Large，不会读取任何请求内容，所以响应极快，内存也不会增长。
• 自定义ActionFilter的问题：ActionFilter属于MVC管道的后期环节，此时请求体已经被完全读取、解析成IFormFile（大文件已经加载到内存），你的校验只是“事后检查”——文件已经上传完了才告诉用户太大，自然耗时久、内存涨。

解决方案：让自定义限制在管道早期生效 #

要达到原生属性的性能，你需要让大小限制逻辑在请求体被读取之前执行，下面是几种可行的方案：

方案1：实现IRequestSizeLimitMetadata接口（最简单）

如果只是需要共享可配置的大小值，直接让自定义属性实现框架的IRequestSizeLimitMetadata接口，这样框架会自动在正确的时机处理：

public class ConfigurableRequestSizeLimitAttribute : Attribute, IRequestSizeLimitMetadata
{
    // 直接使用共享常量，或者从配置读取（需要注入IConfiguration，这里用常量示例）
    public long? MaxRequestSize => SharedConsts.MaximumFileUploadSize;
}

使用方式和原生属性完全一致：

[HttpPost]
[ConfigurableRequestSizeLimit]
public async Task<IActionResult> Upload([FromForm] IFormFile file) { }

这个方案完全复用了框架的底层逻辑，性能和原生RequestSizeLimit一模一样，同时满足了共享配置的需求。

方案2：自定义中间件（适合复杂逻辑）

如果需要更灵活的校验逻辑（比如动态从数据库读取限制值、区分不同用户权限），可以写一个自定义中间件，放在管道的早期位置：

public class RequestSizeLimitMiddleware
{
    private readonly RequestDelegate _next;
    private readonly long _maxUploadSize;

    // 依赖注入配置类，实现可配置
    public RequestSizeLimitMiddleware(RequestDelegate next, IOptions<FileUploadSettings> settings)
    {
        _next = next;
        _maxUploadSize = settings.Value.MaximumFileUploadSize;
    }

    public async Task InvokeAsync(HttpContext context)
    {
        // 先检查Content-Length（适用于非分块请求）
        if (context.Request.ContentLength.HasValue && context.Request.ContentLength > _maxUploadSize)
        {
            context.Response.StatusCode = StatusCodes.Status413PayloadTooLarge;
            await context.Response.WriteAsync("Request content length exceeds the allowed limit.");
            return;
        }

        // 处理分块传输的请求（没有Content-Length的情况）
        var bodyReader = context.Request.BodyReader;
        var readResult = await bodyReader.ReadAtLeastAsync((int)_maxUploadSize + 1, cancellationToken: context.RequestAborted);
        
        if (readResult.Buffer.Length > _maxUploadSize)
        {
            context.Response.StatusCode = StatusCodes.Status413PayloadTooLarge;
            await context.Response.WriteAsync("Request content length exceeds the allowed limit.");
            return;
        }

        // 把已经读取的内容放回，让后续管道继续处理
        bodyReader.AdvanceTo(readResult.Buffer.Start, readResult.Buffer.End);
        await _next(context);
    }
}

// 配置类，绑定appsettings.json
public class FileUploadSettings
{
    public long MaximumFileUploadSize { get; set; } = 104_857_600; // 默认100MB
}

// 扩展方法注册中间件
public static class RequestSizeLimitMiddlewareExtensions
{
    public static IApplicationBuilder UseConfigurableRequestSizeLimit(this IApplicationBuilder app)
    {
        return app.UseMiddleware<RequestSizeLimitMiddleware>();
    }
}

然后在Program.cs中注册：

// 绑定配置
builder.Services.Configure<FileUploadSettings>(builder.Configuration.GetSection("FileUpload"));
// 注册中间件（注意要放在UseRouting之前或之后，确保在MVC管道之前）
app.UseConfigurableRequestSizeLimit();

这个方案可以全局生效，或者结合端点路由针对特定接口生效，性能和原生属性一致，因为它在请求体读取前就拦截了。

方案3：使用EndpointFilter（ASP.NET Core 7+）

如果你的项目是ASP.NET Core 7及以上版本，推荐使用EndpointFilter——它的执行时机比ActionFilter早得多，介于路由匹配和MVC模型绑定之间，也能避免读取整个请求体：

public class RequestSizeLimitEndpointFilter : IEndpointFilter
{
    private readonly long _maxUploadSize;

    public RequestSizeLimitEndpointFilter(IOptions<FileUploadSettings> settings)
    {
        _maxUploadSize = settings.Value.MaximumFileUploadSize;
    }

    public async ValueTask<object?> InvokeAsync(EndpointFilterInvocationContext context, EndpointFilterDelegate next)
    {
        var httpContext = context.HttpContext;
        
        if (httpContext.Request.ContentLength.HasValue && httpContext.Request.ContentLength > _maxUploadSize)
        {
            return Results.BadRequest("Request content length exceeds the allowed limit.");
        }

        // 处理分块请求
        var bodyReader = httpContext.Request.BodyReader;
        var readResult = await bodyReader.ReadAtLeastAsync((int)_maxUploadSize + 1, cancellationToken: httpContext.RequestAborted);
        
        if (readResult.Buffer.Length > _maxUploadSize)
        {
            return Results.BadRequest("Request content length exceeds the allowed limit.");
        }

        bodyReader.AdvanceTo(readResult.Buffer.Start, readResult.Buffer.End);
        return await next(context);
    }
}

使用方式：

[HttpPost]
[EndpointFilter<RequestSizeLimitEndpointFilter>]
public async Task<IActionResult> Upload([FromForm] IFormFile file) { }

总结 #

• 不要用ActionFilter做请求大小限制，因为它执行时机太晚，导致性能问题；
• 最简单的替代方案是实现IRequestSizeLimitMetadata接口，复用框架原生逻辑；
• 复杂场景用自定义中间件或EndpointFilter，确保在请求体读取前拦截。

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