symfony 4 中禁止服务内调用 $container->get()，因其破坏依赖显式性、降低可测试性、掩盖真实依赖并违反控制反转；应改用构造函数注入，特殊情况使用策略工厂或标签化服务。
在 Symfony 4 中，自定义服务里禁止直接获取容器（即避免使用 $container->get()），核心原因是破坏依赖显式性、降低可测试性，并掩盖真实依赖关系。这不是限制，而是为长期可维护性设的边界。
为什么不能在服务里调用 $container->get()
服务类一旦自行从容器取依赖，就等于把“需要什么”藏在了方法内部，而不是通过构造函数清晰声明。这导致：
- 无法一眼看出该服务依赖哪些组件
- 单元测试时难以模拟或替换依赖（得 mock 整个容器）
- 违反控制反转原则——服务不该主动索取，而应被动接收
- 容易引发循环依赖或运行时才暴露的解析错误
正确做法：用构造函数注入替代 get()
所有依赖都应在构造函数中声明类型提示，让容器自动完成注入：
- 写法示例：
public function __construct(private LoggerInterface $logger, private EntityManagerInterface $em) - 确保类在
services.yaml的扫描范围内（如App\:资源已启用autowire: true） - 接口需有对应实现绑定（例如
LoggerInterface默认绑定到monolog.logger）
特殊情况处理：动态/条件性依赖
如果某依赖需根据运行时参数决定（比如不同用户走不同支付网关），不要在服务里 get()，而是：
- 注入一个策略工厂（
PaymentGatewayFactory），由它返回具体实例 - 或使用容器接口 仅限工厂类（工厂本身是服务，且职责就是创建对象）
- 配置多实现+标签（如
app.payment_gateway.stripe,app.payment_gateway.paypal），再通过TaggedIterator或Locator按需选取
误用容器的典型信号
当你在服务方法中看到以下代码，就该重构了：
$this->container->get('doctrine.orm.entity_manager')$this->container->get(UserRepository::class)$this->container->has('some_optional_service')
这些都该转为构造函数参数，或通过更细粒度的服务抽象来解耦。
