symfony 4 中自定义服务只能注入 constraintvalidator 类而非 constraint 类，需通过构造函数声明依赖、在 services.yaml 中注册带 validator.constraint_validator 标签的服务，并确保 validatedby() 返回值与 alias 一致。
在 Symfony 4 中，把自定义服务（比如 UserRepository、EmailService）安全集成进 Validator 校验逻辑，关键不是“能不能用”，而是“在哪用、怎么注入、怎么避免踩坑”。核心原则是：服务只能注入到 ConstraintValidator 类 中，绝不能放进 Constraint 类本身。
Constraint 和 Validator 必须严格分离
Constraint 类（如 UniqueEmail）只负责声明规则元信息：错误消息、可选参数（groups、payload）、验证目标（@Target("PROPERTY")）。它必须可序列化，因此构造函数里不能接收任何服务对象——否则在表单提交或 API 请求反序列化时会直接报错：Serialization of 'Closure' is not allowed 或类似对象引用异常。
真正执行业务逻辑（比如查数据库、调外部 API）的代码，必须写在对应的 ConstraintValidator 子类（如 UniqueEmailValidator）里。这个类才是 DI 容器能管理、能注入依赖的地方。
服务注入必须走构造函数 + 显式服务注册
别指望自动发现或 magic 注入。你需要三步到位：
- 在 Validator 类构造函数中声明类型提示依赖，例如：
public function __construct(private UserRepository $userRepository) {} - 在
config/services.yaml中把它注册为服务，并打上标签：App\Validator\UniqueEmailValidator:<br> tags: [{ name: 'validator.constraint_validator', alias: 'app.validator.unique_email' }] - 确保该服务启用 autowire（默认开启），否则依赖会是
null
同时，Constraint 类中的 validatedBy() 方法返回值，必须和上面 alias 的值完全一致，例如：public function validatedBy(): string { return 'app.validator.unique_email'; }
复合约束（Compound）里复用已有服务逻辑
像 @AtLeastOneOf、@Collection 这类内置复合约束，它们的验证器（如 AtLeastOneOfValidator）是无状态的，不支持注入服务，也不能在其中直接 new 一个带依赖的 Validator 实例。
如果你需要“至少一个字段满足某条带服务的校验”，正确做法是：
- 把整条逻辑封装成一个新的 自定义 Compound Constraint（如
AtLeastOneValidEmail） - 它的 Validator 类里注入所需服务（如
UserRepository） - 在
validate()中手动调用子项的验证，例如：$violations = $context->getValidator()->validate($value['email'], new Email());
或复用已注册的其他 Validator 实例
不要试图往 @AtLeastOneOf(constraints={@UniqueEmail}) 里传一个已注入服务的 UniqueEmail 实例——Constraint 对象本身不含服务，传进去也没用，还可能因序列化失败而崩溃。
验证器内调用其他已注册验证器
当你想在一个自定义 Validator 里复用另一个已注册、带服务的验证逻辑（比如在密码强度校验中顺带检查邮箱是否已被注册），不要复制粘贴 validate 代码，而是用递归验证：
- 通过
$context->getValidator()获取当前验证器实例 - 手动触发子验证：
$subViolations = $context->getValidator()->validate($email, new UniqueEmail()); - 遍历
$subViolations，用$context->buildViolation()转发或包装错误
这种方式天然支持所有已注册的验证器（包括带服务依赖的），且保持单例、可测试、不破坏 DI 原则。
