结论：DataAnnotations特性实现模型验证最高效，但必须依赖框架自动绑定；[Required]对int/DateTime等值类型无效，应改用[Range]或声明为可空类型；ModelState.AddModelError主要用于补充业务规则验证，结构验证由框架自动完成。
核心观点：在C#开发中，为模型添加数据验证，使用[Required]、[StringLength]等DataAnnotations特性是最便捷的方案。然而，其生效的关键前提是必须交由ASP.NET Core或MVC框架的模型绑定器自动处理对象。如果你手动实例化对象（如new User()）并逐一赋值，那么所有验证特性都将失效，无法触发任何验证逻辑。
为什么[Required]特性对int和DateTime类型不起作用？
这个问题根源在于C#的值类型默认值机制。int的默认值是0，DateTime的默认值是DateTime.MinValue，它们天生就拥有一个有效值。因此，[Required]特性仅对可空类型（如int?、DateTime?）或引用类型（如string）有效，用于检测“值是否存在”的状态。
- 如何验证必须大于0的数值字段？ 不要使用
[Required]，应改用[Range(1, int.MaxValue)]特性。对于更复杂的业务规则，推荐集成FluentValidation库，使用[GreaterThan(0)]等语义化规则。 - 如何确保前端必须传递日期值？ 将属性声明为可空类型
DateTime?，然后为其添加[Required]特性。这样框架就能正确识别用户是否提供了该字段的值。 - 常见误区解析： 有时前端提交
"age": null，后端int age属性却收到0。这并非验证失效，而是JSON反序列化器（如System.Text.Json或Newtonsoft.Json）的默认行为所致。
如何在控制器中确保数据验证正确执行？
关键在于模型绑定方式。必须依赖框架的自动绑定机制（如[FromBody]、[FromForm]、路由参数或查询字符串绑定），才能在Action方法执行前自动触发验证流程。
- ✅ 正确做法：
public IActionResult Create([FromBody] User user)—— 框架自动完成模型绑定与验证，并填充ModelState.IsValid状态。 - ❌ 错误做法：
public IActionResult Create() { var user = new User(); user.Name = Request.Form["name"]; ... }—— 此方式完全绕过了验证管道，所有DataAnnotations特性均无效。 - 重要提示： 若模型包含自定义构造函数或属性设置为
private set，必须确保其拥有public get访问器，否则验证器将无法读取属性值进行校验。
验证失败时，应该使用ModelState.AddModelError吗？
该方法确实有用，但主要用于补充业务逻辑验证，而非替代框架的自动结构验证。在标准流程中，只要参数绑定正确，框架会在调用Action方法前自动将数据结构验证错误（如格式错误、必填项为空等）添加到ModelState中。
- 因此，无需在每个Action开头重复编写
if (!ModelState.IsValid) return BadRequest(ModelState);。除非你需要完全自定义错误响应格式，否则此代码通常是冗余的。 ModelState.AddModelError的核心应用场景是添加业务规则错误。例如，在Action中检查邮箱是否已被注册，若重复则可调用ModelState.AddModelError("Email", "该邮箱已被注册")来补充错误信息。- 注意细节： 添加错误时使用的键名（Key）必须与模型属性名称完全一致（包括大小写），否则前端无法正确将错误信息映射到对应表单字段。
最后总结： DataAnnotations特性仅负责数据结构验证（如非空、长度、格式、范围），无法处理数据库唯一性约束、用户权限校验、复杂业务状态流转等业务规则验证。这些业务逻辑应放置在服务层，通过显式判断并结合ModelState.AddModelError或抛出业务异常来处理。明确区分验证职责，才能使代码结构清晰、维护性更强。
