复合约束中调用容器服务需通过constraintvalidator构造函数注入依赖，并在services.yaml中注册为带validator.constraint_validator标签的服务；内置composite约束如atleastoneof不支持注入，服务只能注入验证器而非约束类本身。
复合约束里怎么调用容器里的服务？
Compound约束本身不自动注入服务，必须显式通过ContainerConstraintValidatorFactory配合容器才能拿到$this->userRepository这类依赖。直接在validate()里用new UserRepository()会破坏单例、绕过DI，且无法 mock 测试。
正确做法是让自定义ConstraintValidator继承ConstraintValidator，并在构造函数声明依赖（如private UserRepository $userRepository），然后靠工厂从容器中解析实例——前提是你的验证器类已注册为服务并打上validator.constraint_validator标签。
- 验证器类必须在
services.yaml中声明为服务，并加tags: [{ name: 'validator.constraint_validator', alias: 'app.validator.check_array' }] -
alias值需与约束类中validatedBy()返回的字符串一致（例如return 'app.validator.check_array';） - 别漏掉
autowire: true或显式注入参数，否则依赖为空
AtLeastOneOf 或 Collection 里能用服务吗？
不能。像AtLeastOneOf、Collection这些内置Composite约束只负责组合子约束，不参与业务逻辑执行；它们的验证器（如AtLeastOneOfValidator）是无状态的，不支持依赖注入。想在“至少一个满足”里查数据库？得把整个逻辑封装进一个自定义Compound约束，而不是往AtLeastOneOf里塞@Assert\Callback。
常见错误：在AtLeastOneOf里传入带服务依赖的自定义约束实例——这会导致Constraint对象被序列化失败（因为含闭包或对象引用），抛出Serialization of 'Closure' is not allowed。
- 所有约束对象（
Constraint子类）必须可序列化，因此不能在构造函数里接收服务 - 服务只能注入到对应的
ConstraintValidator中，不能出现在Constraint里 - 若要用
Collection校验一组数据并做跨项查库，应把校验逻辑下沉到每个子项的自定义约束验证器中，而非试图在Collection层面干预
Compound约束如何安全复用已有验证器逻辑？
不要复制粘贴validate()代码。Symfony 的RecursiveValidator支持手动触发子约束验证，你可以用$context->getValidator()->validate($value, $constraint)复用已注册的验证器，包括那些带服务依赖的。
比如你有个UniqueEmailValidator已注册为服务，现在要在StrongPassword这个Compound约束里顺便检查邮箱是否已被占用（假设密码和邮箱同属一个DTO），就可以在StrongPasswordValidator::validate()里调：
$emailConstraint = new Assert\Email();
$emailConstraint->payload = ['source' => 'password_setup'];
$violations = $context->getValidator()->validate($value['email'] ?? '', $emailConstraint);
foreach ($violations as $violation) {
$context->buildViolation($violation->getMessage())
->atPath('email')
->addViolation();
}
-
$context->getValidator()返回的是当前上下文绑定的ValidatorInterface，它已具备完整服务链路 - 避免重复创建
Validation::createValidator()，那会丢失容器上下文 - 注意
$value结构：如果是DTO，确保字段路径匹配；如果是数组，用atPath('email')而非atPath('[email]')
为什么 validate() 里 $context->getObject() 拿不到完整上下文？
当约束目标是PROPERTY_CONSTRAINT（默认），$context->getObject()返回的是当前属性所属的对象实例；但如果约束用在数组元素上（比如Collection内嵌的Compound），$context->getObject()可能只是那个数组项本身，不是原始 DTO。这时$context->getRoot()才是原始数据结构，而$context->getMetadata()->getClassName()可能为空。
真正稳定的上下文入口是$context->getMetadata()->getGroup()和$context->getConstraint()->payload，它们不受嵌套层级影响。需要访问兄弟字段时，优先从$context->getRoot()取值，再用PropertyAccess读取：
$root = $context->getRoot(); $propertyAccessor = PropertyAccess::createPropertyAccessor(); $otherValue = $propertyAccessor->getValue($root, 'username');
- 别依赖
$context->getObject()一定等于根对象，尤其在Collection或AtLeastOneOf内部 -
$context->getRoot()始终指向最外层验证目标，但需确保它不是null（比如验证纯数组时） - 如果
$context->getRoot()不可用，说明验证起点是标量值，此时只能靠payload传参或外部配置驱动逻辑
