[required] 未生效是因为未触发模型绑定，需用[frombody]/[fromform]接收参数；对非空值类型无效；fluentvalidation 适合复杂规则，可与 dataannotations 共存但推荐迁移。
DataAnnotations 的 [Required] 为什么没生效？
常见现象是加了 [Required] 却不报错，提交照样通过。根本原因不是属性没校验，而是没触发校验入口——ModelState.IsValid 只在 MVC / Web API 的 action 参数绑定后自动运行，纯对象 new 出来不会触发。
- 必须让框架接管模型绑定：用
[FromBody]或[FromForm]接收参数，而不是手动 new 对象再赋值 -
[Required]默认只校验引用类型和可空值类型（如string、int?），对int、DateTime这类非空值类型无效（它们总有默认值） - 如果用了自定义构造函数或私有 setter，确保属性有 public getter，否则
ValidationAttribute读不到值 - Web API 中需确认控制器继承
ControllerBase且启用了模型验证（默认开启，但若手动调用TryValidateModel必须传入实例）
FluentValidation 怎么替换掉 DataAnnotations？
不是“替换”，而是分工：DataAnnotations 适合简单标记（如必填、长度），FluentValidation 用来写带逻辑的规则（比如“结束时间必须晚于开始时间”、“邮箱必须属于公司域名”）。两者能共存，但推荐逐步迁移到 FluentValidation，因为它更易测试、支持异步、不污染实体类。
- 安装
FluentValidation.AspNetCore包，Startup.cs 中调用services.AddControllers().AddFluentValidation(...) - 每个 DTO 对应一个继承
AbstractValidator<t></t>的验证器类，例如UserCreateValidator : AbstractValidator<usercreatedto></usercreatedto> - 验证器里用
RuleFor(x => x.Email).Must(BeCompanyEmail).WithMessage("必须使用公司邮箱")，其中BeCompanyEmail是普通 bool 方法，也可用MustAsync - 避免在
RuleFor里直接访问数据库——应把服务注入验证器构造函数，再在Must回调中调用，否则单元测试难 mock
验证失败时怎么返回友好错误？
MVC 和 Web API 默认返回 400 + ModelState 键值对，但前端通常要扁平化错误列表或统一字段名。别靠全局异常过滤器硬改响应体，容易绕过框架的验证流程。
- Web API 中，重写
InvalidModelStateResponseFactory：在AddFluentValidation配置里指定工厂方法，把context.ModelState转成new { errors = ... }格式 - 不要在 action 里写
if (!ModelState.IsValid) return BadRequest(...)——这会重复执行验证，且丢失 FluentValidation 的自定义错误码 - FluentValidation 支持
WithName("email")显式指定字段名，避免因属性重命名导致前端解析失败 - 如果 DTO 有嵌套对象，FluentValidation 默认不递归验证，需显式调用
RuleFor(x => x.Address).SetValidator(new AddressValidator())
性能和兼容性要注意什么？
DataAnnotations 是反射驱动，每次验证都查 Attribute；FluentValidation 编译后是委托调用，快一个数量级。但差异只在高频验证场景（如每秒上千次请求），日常 CRUD 不明显。
- FluentValidation 的验证器类必须注册为 transient（每次请求新建），否则多线程下可能状态混乱
- .NET 6+ 的 Minimal API 默认不启用模型验证，要用
MapPost(...).AddEndpointFilter<validationfilter>()</validationfilter>手动接入 - Blazor Server 中，
EditForm绑定的是EditContext，需配合DataAnnotationsValidator组件——FluentValidation 没官方集成，得自己写ValidationMessageStore同步错误 - 如果 DTO 同时被多个项目引用（如共享类库），DataAnnotations 会把验证逻辑泄露到下游，而 FluentValidation 验证器可只放在 API 层，更干净
最常被忽略的一点：验证只是第一道防线，不能替代领域层的业务规则检查。比如“用户余额足够”这种依赖数据库状态的判断，绝不能塞进 Must 里同步查库，得放到 service 方法里做最终确认。
