Action上的RequestFormLimitsAttribute搭配全局AutoValidateAntiforgeryTokenAttribute失效

问题场景 #

一周前遇到页面返回通用400错误，排查后发现是批量编辑公寓/写字楼地址时，POST提交的表单字段过多触发了默认1024的字段数限制——每套单元对应4个表单字段加额外字段，单元数超250个就会触发问题。尝试给处理POST的Action加RequestFormLimitsAttribute但没生效，下面是几个实用的排查方向：

1. 确认Attribute参数配置到位 #

别只加Attribute，得确保ValueCountLimit设得足够覆盖实际提交的字段数，比如250个单元至少要设到1200以上（留冗余）。正确配置示例：

[RequestFormLimits(ValueCountLimit = 2000)]
public IActionResult BulkUpdateAddresses()
{
    // 业务逻辑
}

注意别混淆参数，比如误设成MultipartBodyLengthLimit这类和字段数无关的配置项。

2. 检查全局配置是否覆盖Action级设置 #

如果项目在Program.cs（或老版本Startup.cs）里全局配置了表单限制，Action级的Attribute可能被覆盖。看看有没有类似代码：

builder.Services.Configure<FormOptions>(options =>
{
    options.ValueCountLimit = 1024; // 这个全局值会优先于Action级配置
});

如果存在全局配置，要么直接提高全局的ValueCountLimit，要么确认Action级配置的优先级——ASP.NET Core中Action级配置本应更高，但如果全局配置后通过中间件做了强制限制，需调整中间件逻辑。

3. 确认使用正确的Attribute命名空间 #

别引用错类！必须是Microsoft.AspNetCore.Mvc.RequestFormLimitsAttribute，部分第三方库可能有同名Attribute，用错了肯定不生效。检查using语句：

using Microsoft.AspNetCore.Mvc; // 确保是该命名空间下的Attribute

4. 验证请求是否到达目标Action #

有时候400错误是在Action执行前就被服务器中间件拦截了，比如IIS的请求过滤规则。可以在Action开头加日志输出，确认请求是否进入处理逻辑。如果没进入，需调整服务器层面的配置：

• IIS环境：检查web.config中的requestFiltering配置，确保无额外字段数或内容长度限制：

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="30000000" />
      <!-- 若存在字段数相关限制，需调整或移除 -->
    </requestFiltering>
  </security>
</system.webServer>

• Kestrel环境：检查Program.cs中的Kestrel配置，避免设置额外请求限制：

builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.Limits.MaxRequestFormSize = 30 * 1024 * 1024;
    // 不要添加字段数相关的强制限制
});

5. 核对表单提交格式是否匹配Attribute适用范围 #

RequestFormLimitsAttribute仅对application/x-www-form-urlencoded格式的表单生效。如果页面使用multipart/form-data（比如包含文件上传），该Attribute无效，需改用RequestSizeLimitAttribute或配置MultipartBodyLengthLimit参数。

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