symfony 中禁用直接调用 $container->get()，应优先通过构造函数注入依赖；若必须使用，需检查服务存在性、设为 public 并避免在构造函数中调用，推荐工厂或服务订阅器等替代方案。
在 Symfony 中，不建议直接调用容器的 get() 方法手动获取服务，这是反模式（anti-pattern），会破坏依赖注入原则、降低可测试性与可维护性。真正规范的做法是通过构造函数或 setter 注入依赖。但若因历史代码、特殊场景（如工厂、动态服务解析）必须使用 get()，需严格规避常见坑点。
避免在控制器/服务中直接调用 $container->get()
直接调用 $container->get('some_service') 会导致：
- 隐藏真实依赖，使类无法被自动装配或静态分析识别
- 违反控制反转（IoC），耦合容器实现（如从 ContainerInterface 换成其他容器会崩溃）
- 单元测试时难以 mock，必须传入完整容器实例
✅ 正确做法：声明类型提示构造参数，让容器自动注入
public function __construct(private readonly MailerInterface $mailer) {}
若必须用 get()，务必先检查服务是否已定义且可访问
Symfony 6+ 默认禁用未注册服务的 public 访问，get() 可能抛出 ServiceNotFoundException 或 InvalidArgumentException（如服务非 public）。务必加防护：
- 确认服务已设为
public: true（YAML）或->setPublic(true)（PHP config） - 优先用
has()判断存在性，再get() - 避免硬编码服务 ID 字符串，改用常量或接口名（如
MailerInterface::class）
if ($container->has(MailerInterface::class)) {
$mailer = $container->get(MailerInterface::class);
}
禁止在服务构造函数中调用容器 get()
这属于循环依赖高危行为。例如 A 服务构造中 $container->get('B')，而 B 又依赖 A，容器无法解析。
- 构造阶段容器尚未完成初始化，部分服务可能不可用
- 延迟加载（lazy）服务也无法在此阶段安全获取
- 应改用
ContainerInterface+get()延迟到方法内调用（但仍属次优解）
替代方案优先级排序（推荐顺序）
当感觉“不得不用 get()”时，先评估以下更健壮的替代方式：
- 工厂服务：将动态创建逻辑封装进专用工厂类，该工厂本身由 DI 容器管理并注入所需依赖
- 服务订阅器（ServiceSubscriberInterface）：在命令、事件监听器等场景中按需获取服务，支持 lazy 加载且类型安全
- 参数包（ParameterBag）+ 条件注入：用配置驱动服务选择，而非运行时字符串查找
-
委托模式：把多态行为抽象为接口，用多个具体实现 + 标签（tags）+ 服务定位器（
TaggedIteratorArgument）
