Symfony 4 中外部类不应直接调用容器获取服务，而应通过构造函数显式注入依赖，以保证可读性、可测试性、单一职责和框架解耦；特殊场景可用 ServiceLocator 但需谨慎。
在 Symfony 4 中，不推荐在自定义服务的外部类（比如普通 PHP 类、DTO、工具类）里直接调用容器获取服务，这不是设计初衷，也违背依赖注入原则。
Symfony 的核心理念是“服务应通过构造函数或方法参数显式注入”，而不是在运行时从容器中“捞”出来。外部类若自行访问容器（如 ContainerInterface::get()），会带来几个明显问题：
- 隐藏依赖关系：类的行为无法从签名看出它依赖什么，破坏可读性和可测试性；
- 难以单元测试：你必须 mock 容器，甚至启动整个 Kernel，导致测试变慢、变脆弱；
- 违反单一职责：类既要完成业务逻辑，又要管理依赖生命周期；
- 耦合框架：代码强依赖 Symfony 容器 API，迁移或复用成本高。
正确做法：把依赖显式传入
如果你有一个工具类 CsvExporter 需要用到 LoggerInterface 和 EntityManagerInterface，不要这么写：
class CsvExporter
{
public function export(array $data): string
{
$logger = $this->container->get(LoggerInterface::class); // ❌ 不推荐
$em = $this->container->get(EntityManagerInterface::class);
// ...
}
}而是改成：
class CsvExporter
{
private LoggerInterface $logger;
private EntityManagerInterface $em;
public function __construct(LoggerInterface $logger, EntityManagerInterface $em)
{
$this->logger = $logger;
$this->em = $em;
}
public function export(array $data): string
{
$this->logger->info('Exporting CSV...');
// 使用 $this->em...
return '...';
}
}然后在服务配置中让容器自动注入（默认已启用 autowire）：
# config/services.yaml
services:
App\Utils\CsvExporter: ~特殊情况：确实需要动态获取（极少数）
比如你在写一个插件式系统，需根据运行时类型决定加载哪个服务，这时可注入 ServiceLocator（需显式配置），而非裸容器：
App\Utils\DynamicProcessor:
arguments:
$serviceLocator: '@App\Utils\DynamicProcessor.locator'
bind:
$supportedTypes: '%app.supported_processor_types%'但这类设计要谨慎评估，优先考虑策略模式或工厂模式替代。
小结
- 外部类 ≠ 容器使用者，它是被容器装配的对象；
- 所有依赖都该声明在构造函数或 setter 中；
- 测试时只需传入 mock 对象，无需启动内核；
- 若发现大量类都在
get()某个服务，说明该服务可能更适合作为参数下沉，或当前架构存在抽象缺失。
不复杂但容易忽略。
