ASP.NET MVC ModelState校验失败但表单数据可正常访问的问题排查

[Bind]特性确实是触发本次ModelState校验失败的根源，但问题不在表单值绑定环节——你调试时能看到Name、Location、MaxCapacity都正确绑定，就是因为这三个字段的绑定逻辑是正常的，校验失败来自未被[Bind]包含的Categories导航属性。

ASP.NET Core 的模型校验是针对整个模型实例执行的，不会因为属性不在[Bind]指定的绑定列表中就跳过对应校验：

1. .NET 6+新建项目默认启用C#可空引用类型，未初始化的ICollection<Category> Categories引用类型属性会被框架默认判定为必填项
2. [Bind]特性只会阻止给列表外的属性赋值，不会阻止框架对这些属性执行校验，最终Categories属性因为为null、又被判定为必填，就会在ModelState中生成校验错误，导致ModelState.IsValid始终返回false。

你可以在Action中加如下代码遍历ModelState错误，就能看到具体报错字段是Categories，和你提交的三个表单字段无关：

foreach (var modelError in ModelState)
{
    var errors = modelError.Value.Errors;
    if (errors.Count > 0)
    {
        Console.WriteLine($"字段{modelError.Key}报错：{string.Join(",", errors.Select(e=>e.ErrorMessage))}");
    }
}

按推荐优先级从高到低排列：

• 最佳实践：使用独立视图模型（DTO）接收表单参数
  不要直接将EF Core数据库实体作为Action入参，单独创建仅包含表单提交字段的视图模型，校验通过后再手动映射为Warehouse实体入库。这种方式从根源上避免导航属性、多余数据库字段带来的绑定/校验问题，也能彻底防住过度提交安全风险。
• 快速修复：修改实体定义，跳过导航属性的绑定与校验
  给导航属性添加[BindNever]特性标记，同时将其声明为可空引用类型，避免触发非空校验，修改后的实体代码如下：

  public class Warehouse
  {
      [Key]
      public int Id { get; set; }
      [Required]
      [StringLength(30, ErrorMessage = "Name should have less than 30 characters")]
      [DisplayName("Warehouse Name")]
      public string Name { get; set; } = string.Empty;
      [Required]
      public string Location { get; set; } = string.Empty;
      [Required]
      public int MaxCapacity { get; set; }
  
      // 标记为不参与绑定/校验，声明为可空类型
      [BindNever]
      public ICollection<Category>? Categories { get; set; }
  }
  

• 临时修复：手动清除无关字段的校验错误
  如果不想修改实体定义，可以在判断ModelState.IsValid前，手动移除Categories字段对应的校验状态：

  [Route("Create")]
  [HttpPost]
  [ValidateAntiForgeryToken]
  public IActionResult Create([Bind("Name, Location, MaxCapacity")] Warehouse warehouse)
  {
      // 清除导航属性对应的校验错误
      ModelState.Remove("Categories");
      
      if (ModelState.IsValid)
      {
          _Db.Add(warehouse);
          _Db.SaveChanges();
          return RedirectToAction("Index");
      }
  
      return BadRequest();
  }
  

  这种方式硬编码了属性名字符串，后续实体属性改名时容易遗漏修改，不推荐在生产环境长期使用。

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