Symfony服务容器通过声明依赖自动注入，无需手动new或get()；推荐构造函数注入，支持自动装配和接口绑定，手动配置仅用于特殊场景。
Symfony服务容器不是“用”出来的，而是你声明依赖后，它自动为你准备好的。核心逻辑就一条：你告诉容器“我需要什么”，它负责把东西递到你手上——不用new，不手动找依赖，也不直接调用$container->get()。
构造函数注入是最自然的用法
这是官方推荐、最清晰也最易测试的方式。只要你的类有明确的类型提示，容器就能自动把对应服务塞进去。
- 写一个服务类，比如
App\Service\PaymentProcessor，构造函数里写明依赖：public function __construct(private CreditCardGateway $gateway, private LoggerInterface $logger) {} - 确保这个类在
src/下，并且config/services.yaml里开启了自动装配（默认已开）：_defaults: { autowire: true, autoconfigure: true } - 在控制器、命令或另一个服务里，直接把
PaymentProcessor当参数写进构造函数或方法签名，容器会自动实例化并注入所有依赖
手动配置服务适用于特殊场景
当自动装配不够用时——比如要传具体参数、换实现类、控制可见性或作用域——就得去config/services.yaml里写明。
- 定义一个带参数的服务：
App\Service\FileLogger:<br> arguments:<br> $path: '%kernel.project_dir%/var/log/app.log'
- 替换某个核心服务的实现：
Symfony\Component\Mailer\MailerInterface:<br> class: 'App\Service\CustomMailer'
- 让服务只在当前请求内有效（避免跨请求状态污染）：
App\Service\RequestContext:<br> scope: 'request'
别直接从容器里拿服务
像$this->container->get('App\Service\Something')这种写法，只应在极少数无法注入的上下文（如某些事件监听器早期阶段）临时使用。它破坏了依赖显式声明的原则，让类难以独立测试，也绕过了自动装配和类型检查。
- 如果你发现某处必须这么写，先检查是否遗漏了
public: true（私有服务不能被get()获取） - 更推荐的做法是：把这个逻辑封装成一个新服务，然后通过构造函数注入进来
- 控制器中获取服务？应该用参数注入；命令类中？同样走
__construct()；Twig扩展？用setContainer()方法或改用服务注入方式
接口绑定让代码更灵活
不硬绑具体类，而是绑定接口到实现，后续换实现只需改配置，不用动业务代码。
- 在
services.yaml里加一行：Psr\Log\LoggerInterface: '@monolog.logger' - 你的任意类只要声明
LoggerInterface类型提示，就会自动拿到Monolog实例 - 想换成自定义日志器？只改这一行，其他地方完全无感
