c#如何使用FluentValidation_c#FluentValidation项目实例附完整源码

FluentValidation 验证器不生效的主因是未正确注册或调用：需在 ASP.NET Core 中注册服务并启用 MVC 集成，验证器类名须以 Validator 结尾且继承 AbstractValidator，手动调用时应从 DI 解析以避免构造失败导致静默退化。

FluentValidation 验证器不生效，Validate 返回 IsValid == true 却没报错？

遇到这种情况，先别急着怀疑规则写错了。最常见的原因，其实是验证器压根没被正确“激活”或调用。这里有个关键认知：FluentValidation 本身并不会自动拦截模型绑定。它不像 DataAnnotations，靠一个 [Required] 特性就能触发。你必须显式调用 Validate 方法，或者在 ASP.NET Core 中完成服务注册并启用 MVC 集成，它才能真正参与到请求验证的生命周期里。

• 在 ASP.NET Core 项目中，如果漏掉了 services.AddControllers().AddFluentValidation(...) 这关键一步，那么你写的验证器就只是一个普通的类，完全不会对传入的请求数据做任何检查。
• 手动调用时，直接 new PersonValidator().Validate(person) 看似没问题。但如果你的验证器构造函数依赖了 IOptions 这类服务，而你又没从 DI 容器去解析它，就会导致构造失败。这时，FluentValidation 会静默退化为一个默认的空验证器，结果自然是 IsValid == true，让你误以为验证通过了。
• 验证器的命名和继承也有讲究。类名必须以 Validator 结尾（比如 PersonValidator），并且必须继承 AbstractValidator。否则，AddFluentValidation 的自动扫描机制会直接跳过它，导致注册失败。

ASP.NET Core 中如何让 FluentValidation 替代默认的 ModelState 验证？

更准确的说法不是“替换”，而是“接管”。我们的目标是通过配置，让 MVC 框架使用 FluentValidation 的验证结果来填充 ModelState。只有这样，后续的 ModelState.IsValid 判断和前端 TagHelper 的错误提示，才能真正反映出你精心编写的 FluentValidation 规则。

• 在 Program.cs 中，通常需要这样配置： services.AddControllers().AddFluentValidation(fv => { fv.AutomaticValidationEnabled = false; fv.RunDefaultMvcValidationAfterFluentValidationExecutes = false; });
• 这里有两个关键配置：AutomaticValidationEnabled = false 是为了禁用自动验证（避免与手动调用冲突）；RunDefaultMvcValidationAfterFluentValidationExecutes = false 则是为了防止 DataAnnotations 再跑一遍，从而干扰或重复错误信息。
• 确保你的验证器已被注册。如果只需要客户端适配，可以添加：services.AddFluentValidationClientsideAdapters();。更常见的做法是启用自动验证：services.AddFluentValidationAutoValidation();（这需要配合上述配置来控制验证时机）。

RuleFor(x => x.Email) 报错 “Expression not supported”？

这个错误通常源于 LINQ 表达式树的限制。当你试图对非公共属性、字段，或者包含复杂操作（如方法调用、空条件运算符 ?.）的表达式进行验证时，就可能触发。

• 一个典型的场景是：RuleFor(x => x.Address?.City)。这里的 ?. 操作符目前不被 FluentValidation 的表达式解析器支持。
• 解决办法是使用 When 条件配合显式的属性访问：
  RuleFor(x => x.City).NotEmpty().When(x => x.Address != null);
• 另一个常见的坑是：RuleFor(x => x.FullName.ToUpper())。ToUpper() 是一个运行时方法调用，无法直接转换为表达式树。正确的做法是拆成两步：先验证 FullName 非空，然后在自定义验证逻辑里处理大小写转换。
• 如果确实需要校验嵌套对象的字段，推荐的做法是将验证逻辑下沉。为子对象（如 Address）定义自己的 AbstractValidator
  ，然后在父验证器中使用 SetValidator 进行关联：
  RuleFor(x => x.Address).SetValidator(new AddressValidator());

为什么 ValidateAsync 性能反而比同步 Validate 差？

这其实是一个选择问题。除非你的验证规则里确实包含了 I/O 操作（比如查询数据库、调用 HTTP API），否则使用 ValidateAsync 只是在同步逻辑外包了一层 Task.CompletedTask。在纯 CPU 计算的场景下，异步状态机的开销、以及可能引发的上下文捕获，反而会导致性能下降。

• 异步验证应该只在规则中调用了真正的 async 方法时使用，例如：
  RuleFor(x => x.Email).MustAsync(async (email, ct) => !await _userRepository.ExistsAsync(email, ct));
• 注意，混合使用可能会出问题。如果一个验证器里同时包含了同步的 Must 和异步的 MustAsync，你必须全部使用 ValidateAsync 来调用，否则异步规则会被默默忽略。
• 另外，ASP.NET Core 的自动验证集成默认只调用同步的 Validate 方法。如果你想走异步路径，需要自己重写 IObjectModelValidator，或者使用 FluentValidation.AspNetCore 提供的 AddFluentValidation 方法并启用 EnableClientSideValidation = true（其内部会按需选择同步或异步路径）。

最后提一个容易被忽略的点：验证上下文（ValidationContext）的复用和自定义。比如，当需要进行跨多个属性的联合校验，或者需要注入当前用户权限时，直接 new 一个 context 很容易丢失 RootContextData 或服务解析能力。这时候，与其把复杂逻辑硬塞进 Must 里，不如更稳妥地使用 Custom 方法，配合 context.GetRootData() 来实现，代码会更清晰、更健壮。