C#怎么实现数据验证_C# DataAnnotations模型验证教程【实战】

结论：用DataAnnotations特性最省事，但需确保模型由框架自动绑定；[Required]对int/DateTime无效因其有默认值，应改用[Range]或声明为可空类型；验证失败时ModelState.AddModelError仅用于业务规则，结构验证由框架自动完成。

开门见山，先说结论：想给模型加验证，用 [Required]、[StringLength] 这类 DataAnnotations 特性确实是条捷径。但这里有个关键前提——你得让 ASP.NET Core 或 MVC 的模型绑定机制“亲自”处理你的对象。如果自己手动 new User() 然后挨个属性赋值，那对不起，你贴再多的验证特性也形同虚设，一个都不会触发。

为什么 [Required] 对 int 和 DateTime 总是通过？

这事儿其实不怪 [Required]，得怪 C# 的默认值机制。你想啊，int 的默认值是 0，DateTime 的默认值是 DateTime.MinValue，它们天生就“有值”。[Required] 特性只对可空类型（比如 int?、DateTime?）或者引用类型（比如 string）才真正管用。

• 那怎么校验一个必须大于0的数值字段呢？很简单，别用 [Required]，改用 [Range(1, 100)]。如果需求更复杂，可以考虑引入 FluentValidation 库，用 [GreaterThan(0)] 这样的自定义规则。
• 想强制前端必须传一个日期过来？先把属性声明为可空的 DateTime?，然后再给它加上 [Required] 特性，这样框架就能正确识别“未提供值”的状态了。
• 这里还有个常见的误解：有时候前端明明传了 "age": null，后端收到的 int age 却变成了 0。这其实不是验证失效，而是 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 或者抛出业务异常来处理。分清职责，代码才能既清晰又健壮。