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)没问题，但若 validator 构造依赖IOptions<myconfig></myconfig>等服务，而你没从 DI 容器解析，就会因构造失败静默退化为默认空验证器（IsValid == true） - 验证器类名必须以
Validator结尾（如PersonValidator），且继承AbstractValidator<t></t>，否则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非空，再在自定义验证器里处理大小写逻辑 - 如果真要校验嵌套对象字段，推荐把验证逻辑下沉到子对象自己的
AbstractValidator<address></address>中，并用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)); - 混合使用会出问题：一个 validator 里既有同步
Must又有异步MustAsync，必须全部用ValidateAsync调用，否则异步规则会被忽略 - ASP.NET Core 自动集成默认只调用同步
Validate，想走异步路径得自己重写IObjectModelValidator或改用FluentValidation.AspNetCore提供的AddFluentValidation并启用EnableClientSideValidation = true（它内部会按需选同步/异步）
FluentValidation 最容易被忽略的其实是验证上下文（ValidationContext）的复用和自定义——比如需要跨多个属性做联合校验、或注入当前用户权限时，直接 new context 很容易丢掉 RootContextData 或服务解析能力。这时候别硬塞逻辑进 Must，老实用 Custom 方法配 context.GetRootData() 更稳。
