C#怎么创建FluentValidation_C#流式验证规则配置使用教程【实战】

FluentValidation 正确运行需三要素：继承 AbstractValidator、RuleFor 写在构造函数中、验证时传入非 null 实例；否则易静默返回 true 或抛 NullReferenceException。

很多开发者容易把 FluentValidation 当成一个“配置完就能用”的黑盒，结果一跑起来就踩坑。其实，它的稳定运行依赖于三个明确的先决条件：正确继承 AbstractValidator、将规则定义写在构造函数里、以及验证时传入一个真实的对象实例。这三者缺一不可，否则，Validate() 方法要么会静默地返回一个 IsValid = true 的假象，要么直接抛出令人头疼的 NullReferenceException。

怎么写一个能跑起来的验证器类

核心原则其实非常明确：你的验证器类必须继承自 AbstractValidator，并且所有的 RuleFor 调用都必须放在构造函数内部。如果把规则写在别的地方，比如一个单独的方法里或者静态初始化块中，那么这些规则在验证时根本不会生效。

• 这里有个细节：RuleFor 的 lambda 表达式参数必须是直接的属性访问，比如 x => x.Name。如果写成计算属性或方法调用（例如 x => x.FullName.ToUpper()），编译阶段就会报错。
• 如果你的验证目标是 record 类型或者包含只读属性，务必确保该属性有 getter 访问器，否则 RuleFor 将无法成功绑定。
• 另外，切记不要在构造函数内部去实例化另一个验证器并直接调用其 Validate() 方法。这么做会完全绕过 FluentValidation 内置的验证上下文和级联逻辑，导致行为不可预测。

为什么 Validate() 总是返回 IsValid = true

遇到验证器总是“开绿灯”，最常见的原因就是传入的验证对象本身是 null。FluentValidation 默认并不会去校验输入对象是否为空，它的逻辑是直接遍历对象的属性来应用规则。那么问题来了，如果传入的是 null，RuleFor(x => x.Name) 中的 x 就成了空引用，整个表达式求值会失败。框架会捕获这个异常，但默认行为是跳过这条规则——不报错，也不记录任何错误信息，最终返回一个“看似有效”的结果。

• 解决方案是显式检查 null：在调用 Validate() 之前，先加一层判断，比如 if (user == null) return new ValidationResult(...)。
• 需要警惕的是，内置的 NotNull() 规则只能校验某个属性值是否为空，无法校验根对象本身。校验根对象是否为 null，通常需要业务逻辑层来把关。
• 调试时，别只盯着 result.IsValid 看。有时候错误信息可能被“吞”了，但 result.Errors 集合里可能有内容，打印一下它的长度是个好习惯。

RuleSet 用错会导致验证完全不触发

把 RuleSet 理解成一个简单的开关就错了，它实际上是一个命名规则分组。关键在于，如果不显式指定 IncludeRuleSets 选项，那么 Validate() 方法默认只会执行那些“无名”的规则，也就是没有包裹在任何 RuleSet 块里的规则。

• 举个例子：你定义了 RuleSet(“Create”, () => { … })，但调用时却用了 validator.Validate(obj)。结果就是，花括号里的所有规则都不会被执行。
• 正确的调用方式是：validator.Validate(obj, opt => opt.IncludeRuleSets(“Create”))。
• 当然，你可以同时启用多个规则集：opt.IncludeRuleSets(“Create”, “EmailCheck”)。
• 最后注意一点，规则集的名称是大小写敏感的，“create” 和 “Create” 会被视为两个完全不同的集合。

ASP.NET Core 自动验证失效的几个硬坑

即便你已经安装了 FluentValidation.AspNetCore 包并正确注册了服务，自动模型验证仍然可能失效。问题往往出在模型绑定阶段之前，或者简单的类型匹配上。

• 控制器 Action 的参数类型，必须与验证器的泛型参数严格一致。比如，你的验证器是 UserDtoValidator : AbstractValidator，那么对应的 Action 参数就必须是 UserDto 类型，使用 object 或其基类都会导致验证器不被触发。
• 如果没有调用 services.AddFluentValidationClientsideAdapters()，那么前端的 Ja vaScript 验证将不会自动生成，但后端的验证逻辑通常不受影响。
• 当使用 [FromBody] 绑定 JSON 时，如果 JSON 中的字段名与 C# 模型属性名不匹配（例如属性上标注了 [JsonPropertyName(“user_name”)]），而验证器里写的却是 RuleFor(x => x.UserName)，验证依然会通过。这是因为验证器操作的是反序列化后的对象，而非原始的 JSON 字符串。
• 如果你自定义实现了 IValidatorFactory，千万要确保其 GetValidator 方法不返回 null。一旦返回 null，框架会静默地跳过验证，不会抛出任何异常，这很容易让人误以为验证通过了。

话说回来，像 RuleSet 和级联模式（CascadeMode.Stop）这类机制，表面上看是功能开关，实际上它们是控制整个验证流程的“断点”和“路径选择器”。改动其中一处，整条验证链的行为都可能发生变化。因此，务必在单元测试中覆盖所有涉及 RuleSet 的分支路径，这才是保证验证逻辑健壮性的关键所在。