FluentValidation中RuleFor链式调用顺序决定执行顺序，NotNull()等基础规则应前置，Must()等业务规则后置；条件规则When/Unless依赖前置结果，需避免副作用逻辑被短路。
FluentValidation 中 RuleFor 的链式调用顺序影响校验结果
校验规则的声明顺序直接决定执行顺序，而 When、Unless、DependentRules 等条件控制逻辑依赖于前置规则是否“触发”或“失败”。比如，若把 NotNull() 放在 Must() 后面，且 Must() 抛异常或返回 false，NotNull() 可能根本不会执行——这不是 bug，是设计使然。
实操建议：
-
RuleFor(x => x.Email)后优先接基础非空、格式类规则（如NotEmpty()、EmailAddress()），再接业务语义规则（如Must(BeUniqueEmail)） - 需确保某规则**一定执行**（例如日志记录或副作用），不要依赖它前面的规则成功；改用
Custom或拆到独立RuleSet - 调试时开启
ValidatorOptions.Global.CascadeMode = CascadeMode.StopOnFirstFailure（默认），避免误判“没跑”是 bug，其实是被短路了
如何让 ValidateAsync 正确处理 CancellationToken 并避免死锁
异步校验器（如访问数据库查重）必须显式支持 CancellationToken，否则可能阻塞请求线程或无法响应取消信号。常见错误是直接在 MustAsync 里调用同步 DB 方法，或忽略传入的 token。
实操建议：
-
MustAsync的委托签名必须是Func<t propertyname cancellationtoken task>></t>，漏掉CancellationToken参数会导致编译通过但运行时不传递 token - 避免在
MustAsync内部调用.Result或.Wait()—— 这会引发死锁，尤其在 ASP.NET Core 同步上下文环境中 - 若底层仓储方法不支持 token（如旧版 Dapper），应包装为
Task.Run(() => ...)并显式传入 token，但注意这仅移出同步块，不解决真正异步 I/O
在 ASP.NET Core 中集成 FluentValidation 时，AddFluentValidation 和手动注册的区别
官方推荐的 services.AddFluentValidation(...) 是便捷入口，但它默认只扫描程序集内继承 AbstractValidator<t></t> 的类型，并自动绑定到对应 T。一旦涉及泛型验证器、多租户场景或需要复用同一验证器实例，这个自动绑定就会失效。
实操建议：
- 不要依赖自动发现来注册
AbstractValidator<mycommand>></mycommand>这类泛型验证器——必须手动services.AddSingleton<ivalidator>>>(sp => new MyCommandValidator<int>())</int></ivalidator> - 若验证器构造函数依赖
IHttpContextAccessor或ClaimsPrincipal，需用AddTransient而非AddSingleton，否则跨请求状态污染 - 启用客户端验证（
options.EnableClientSideValidations = true）后，务必确认模型属性有正确[Required]等 DataAnnotation 标签——FluentValidation 不生成 JS 规则，它只补服务端逻辑
RuleSet 不是命名空间，而是可组合、可嵌套的执行单元
RuleSet 常被误认为“分组标签”，实际它是 FluentValidation 的执行调度机制：调用 Validate(..., ruleSet: "Create") 时，只有该 RuleSet 内规则和未归类的规则（即不在任何 RuleSet 中的）会执行；而 Include 可跨 RuleSet 复用逻辑，DependentRules 则可实现“前一条失败就不执行后续”这类细粒度控制。
实操建议：
- 不要为每个 API 接口建一个 RuleSet（如 "PostUser"、"PutUser"）——应按业务阶段建，如 "Basic"、"BusinessLogic"、"IdempotencyCheck"
-
Include引用的是另一个验证器的RuleSet，不是类型名；写成Include("Basic")前，要确保被包含的验证器也定义了同名 RuleSet - 在
RuleSet("Save")中调用RuleFor(x => x.Id).NotEmpty().When(x => x.Id == 0)是无效的——When条件在 RuleSet 外层已求值，应改用DependentRules或拆成两个独立 RuleSet
最易被忽略的是：FluentValidation 的错误消息模板（如 WithMessage("邮箱已被注册")）在多语言场景下必须配合 IStringLocalizer 手动注入，它不自动读取 SharedResources；而 ResourceName + ResourceType 方式又要求资源键严格匹配，稍有拼写偏差就回退到英文原串——这里没有魔法，只有显式绑定。
