控制器依赖注入需继承AbstractController并启用autowire，服务类须在扫描路径内、有准确类型提示且接口已绑定实现；标量和实体不可直接注入。
控制器里直接用类型提示就能注入服务，前提是它得是容器里的合法服务——不是所有类都能自动塞进去，得满足几个硬性条件。
控制器必须继承 AbstractController
这是最常见也最容易被跳过的一步。如果你的控制器没继承 Symfony\Bundle\FrameworkBundle\Controller\AbstractController，哪怕 services.yaml 配置全对，依赖注入也会失败，报错类似：
RuntimeException Could not resolve argument $repository of "App\Controller\MyController::index()"
- 继承
AbstractController后，Symfony 默认会把它注册为服务，并自动打上controller.service_arguments标签 - 不继承的话，即使你在
services.yaml里手动注册并加标签，也容易漏掉或配错 - 继承还能顺带用上
$this->render()、$this->redirectToRoute()这些快捷方法，不用自己写一堆new Response()
服务本身得能被自动装配（autowire）
控制器能“要”服务，不代表容器“有”服务。服务类自己得满足 autowiring 条件：
- 类必须在
services.yaml的自动扫描路径里（默认是App\: { resource: '../src/' }） - 构造函数参数要有明确的类型提示，比如
MailerInterface、EntityManagerInterface，而不是array或string - 接口得有对应实现绑定，例如
MailerInterface默认由mailer.mailer提供，不需要额外配置 - 如果用了自定义服务类（如
App\Service\ReportGenerator），确保它没被exclude规则屏蔽（比如别误写在exclude: '../src/Entity/**'里）
注入位置：方法参数比构造函数更常用
在 Symfony 控制器中，90% 的场景推荐把服务放在动作方法（action method）参数里，而不是构造函数：
- 方法参数注入更轻量，只在真正调用该路由时才解析依赖，避免冷启动加载一堆不用的服务
- 支持按需注入，比如一个控制器有
index()和export()两个方法，只有后者需要CsvExporter，那就只在export(CsvExporter $exporter)里声明 - 构造函数注入也可以，但会让整个控制器生命周期都持有该服务实例，可能带来内存或状态残留风险
- 注意：方法参数注入依赖
controller.service_arguments标签，而这个标签正是继承AbstractController后自动获得的
标量参数和实体不能直接注入
有些东西容器根本不会帮你猜，强行类型提示只会报错：
-
string $apiEndpoint、int $maxRetries这类标量，必须通过bind:或arguments:在services.yaml显式配置 - Doctrine 实体（如
App\Entity\User）不是服务，不能当构造函数参数注入——它应该由 Repository 查出来，再作为方法参数传入业务逻辑 - 如果你在控制器方法里写了
public function show(User $user)，这其实是路由参数绑定（靠 ParamConverter），和 DI 容器无关；真要注入服务，类型必须是服务类或接口
最常被忽略的一点：检查 config/services.yaml 里是否意外关闭了 autowire: true 或删掉了 App\: 的 resource 配置——这类配置错误不会报错，但会让所有自动注入静默失效。
