Symfony控制器构造函数不支持自动服务注入，是框架设计限制；正确做法是使用方法参数注入（如index(MailerInterface $mailer)）或继承AbstractController后调用其辅助方法，业务逻辑应下沉至独立服务类。
控制器构造函数不能直接注入服务
Symfony 控制器类的构造函数不支持自动服务注入——这不是配置问题，而是框架设计限制。即使你写了 __construct(LoggerInterface $logger)，容器也不会调用它来实例化控制器。你看到的“控制器里用了服务”，实际是靠 AbstractController 提供的延迟访问机制或方法参数注入实现的。
正确做法：用方法参数或 AbstractController 辅助方法
要使用服务，必须避开构造函数，改用以下两种方式之一：
- 在控制器方法签名中直接声明依赖，比如
public function index(MailerInterface $mailer, UserRepository $userRepository): Response—— Symfony 会自动解析并传入 - 继承
AbstractController，然后在方法里用$this->get('service_id')或更推荐的$this->container->get(ClassName::class)（仅限调试或极特殊场景） - 若需复用逻辑，把真正需要服务组合的代码抽到独立服务类中，再通过方法参数注入该服务
为什么构造函数被跳过？
Symfony 的控制器工厂默认不走构造函数注入流程，而是用反射获取方法参数类型，再按需解析依赖。这带来几个实际影响：
- 构造函数里写
private readonly LoggerInterface $logger不会生效，运行时抛出Too few arguments - 无法在构造阶段初始化依赖相关的状态（比如预加载配置），必须推迟到方法执行时
- 如果你强行在
services.yaml中为控制器类配置arguments:，会覆盖默认工厂行为，但极易破坏路由参数绑定（如{id}变成字符串而非实体）
想提前拿到服务？用 __invoke() 或 setter
极少数场景（比如控制器作为可调用对象注册为事件监听器），可以定义 __invoke() 方法并让它接收服务参数；或者用 setter 注入，但要注意：
- setter 必须显式在
services.yaml中配置calls:，例如：App\Controller\ReportController: calls: - [setMailer, ['@mailer.default']] - setter 注入的服务无法参与自动类型推断，得手动写服务 ID，且容易和路由参数混淆
- 这种方式绕过了标准控制器生命周期，测试和调试成本明显上升
真正稳定的路径，始终是把业务逻辑下沉到服务层，控制器只负责协调请求、响应和参数传递——构造函数不该承担这个责任。
