Symfony注入MailerInterface依赖至App\Util类时报构造参数缺失错误

结合你给出的报错特征和配置信息，可以按以下顺序定位问题：

• 首先优先检查：是否在业务代码里直接写了new OwnerMailValidation()来实例化这个类
  你现在遇到的“构造函数期待1个参数，实际传入0个”是手动实例化服务类的典型报错。Symfony的所有依赖注入配置，只对容器解析生成的类实例生效；如果绕过容器直接手动new类，完全不会走参数注入流程，自然就会报参数不足的错。
  正确的使用方式是：在需要调用这个类的位置（控制器、其他服务的构造函数）直接声明OwnerMailValidation类型的依赖，由容器自动生成带完整依赖的实例，不要手动写new。
• 检查构造函数引入的MailerInterface是否和项目实际的邮件组件匹配
  开启全局autowire的前提下，容器会自动匹配构造函数的类型提示到对应实现，根本不需要手动在services.yaml里加参数配置。这里容易踩的坑是：新旧邮件组件的接口命名不一致——新版Symfony Mailer的接口是Symfony\Component\Mailer\MailerInterface，旧版Swift Mailer的接口是Swift_Mailer，如果引入了错误的接口类，会导致自动绑定失效。不过这类问题的报错一般是“找不到对应服务”，和你当前的报错特征不完全匹配。
• 确认配置生效状态、清理编译缓存
  你的services.yaml里，App\ 资源段已经自动扫描了src/目录下的所有类注册为服务，全局已经开启autowire，那你后面单独写的App\Util\OwnerMailValidation配置段本身就是冗余的，如果缩进格式有问题反而可能导致服务定义解析异常。
  另外Symfony的服务容器是带编译缓存的，每次修改服务配置后必须执行php bin/console cache:clear清掉旧缓存，否则容器会沿用之前的旧服务定义，不会加载你新加的参数配置。
• 核对手动配置的服务别名是否存在
  你写的参数配置里用了@mailer作为服务名，这个别名在旧版Swift Mailer组件中是存在的，但在新版Symfony Mailer组件中默认没有这个别名，错误的服务名也会导致参数注入失败。

内容的提问来源于stack exchange，提问作者Felix