Symfony 7验证组件是强制执行层，规则主干写在实体注解，非映射字段在FormType中配置constraints，跨字段或查库验证需Callback或自定义Constraint，手动验证须调用ValidatorInterface::validate()。
Symfony 7 的验证组件不是“可选插件”，而是数据合法性判断的强制执行层：所有可信校验必须由 ValidatorInterface 在服务端触发，前端 JS 或 HTML5 属性仅作辅助体验，不能替代。
验证规则该写在哪儿？实体注解是主干，FormType 是补丁
核心业务约束（如邮箱格式、非空、长度）必须落在实体类属性上，用注解声明。这样规则随数据模型走，复用性高，且能被 Doctrine、API Platform 等其他组件识别。
-
@Assert\NotBlank、@Assert\Email、@Assert\Length直接写在实体字段上，比如email或password - 不映射到实体的字段（如
plainPassword、termsAccepted），必须在FormType中通过'constraints' => [...]显式添加 -
RepeatedType字段无需手写“两次输入一致”逻辑——它内置比对，只要两个子字段名匹配（如first_options['attr']['name']和second_options['attr']['name']），验证就自动生效 - 字段名与实体属性名不一致时，必须用
'property_path' => 'xxx'指定映射路径，否则注解约束完全不触发
跨字段或查库验证？别硬塞注解，用 Callback 或自定义 Constraint
注解只能描述单字段静态规则。一旦涉及字段联动（如结束时间 ≥ 开始时间）、外部依赖（如用户名是否已存在），就得跳出注解体系。
-
@Assert\Callback放在实体里，适合轻量联动逻辑：方法接收ExecutionContextInterface，调用$context->buildViolation(...)->atPath('fieldName')->addViolation() -
@Assert\Expression适合简单计算，比如"this.getEndDate() >= this.getStartDate()"，但无法注入服务或查数据库 - 需查库（如唯一性校验）必须写自定义 Constraint 类，继承
ConstraintValidator，在validate()方法里注入UserRepository等服务——注意：该类必须声明为public服务，否则容器无法自动注入
手动验证对象？别绕过 ValidatorInterface，也别漏掉上下文
控制器里有时需要脱离表单流程单独验证一个对象（比如 API 请求体反序列化后的 DTO），这时必须显式调用 ValidatorInterface::validate()，而不是靠表单 isValid() 隐式触发。
- 直接注入
ValidatorInterface，传入待验对象，得到ConstraintViolationListInterface - 检查
count($errors) > 0后，不要只抛异常；应把$errors传给响应构造器，或转成结构化数组返回给前端 - 若要复用表单级错误渲染逻辑（如 Twig 中的
{{ form_errors(form.email) }}），得确保验证上下文与表单绑定一致——通常意味着不该手动验证，而应走完整表单流程 - 验证失败时，
$error->getPropertyPath()返回的是对象属性路径（如email），不是表单字段名（如user[ email ]），两者不等价
真正容易被忽略的点是：验证错误归属和渲染路径严格依赖“字段映射关系”。哪怕规则写对了，只要 property_path 缺失、mapped => false 忘加 constraints、或自定义 Constraint 没设为 public 服务，错误就会静默丢失——既不报错，也不显示。
