symfony中动态注入可变依赖需区分编译期与运行时场景：编译期用compiler pass批量注册带字面量参数的工厂服务；运行时用闭包工厂或表达式语言延迟解析。
在 Symfony 中，工厂类动态注入“可变依赖”——即每次调用工厂方法时传入不同参数（如服务类名、配置键、运行时上下文等）——不能靠常规的 arguments 静态配置实现，而需结合容器编译期机制与运行时委托。核心在于：**让工厂本身是固定的，但它的调用参数由容器在实例化时动态决定**。
用编译器 Pass 批量注册带动态参数的工厂服务
这是处理大量旧服务集成或泛型服务代理的推荐方式。关键不是让工厂“自己决定参数”，而是让容器在编译阶段为每个目标服务生成一个专属服务定义，并把参数（如 FQCN）作为 factory 调用的字面量传入。
- 给旧服务类打自定义标签（例如
old_app.service），并在编译器 Pass 中扫描所有带该标签的服务定义 - 对每个匹配的服务，用
Definition::setFactory()指向统一工厂类的静态方法或实例方法，并显式设置参数数组：['AppServiceOldAppServiceFactory', 'create']+[$fqcn] - 这样生成的最终容器代码中，每个服务对应一行类似
(new OldAppServiceFactory())->create('App\Service\LegacyMailer')的调用
用服务闭包（Closure Factory）实现运行时参数绑定
适用于参数来自请求上下文、用户会话或配置驱动等无法在编译期确定的场景。不注册具体服务，而是注册一个返回闭包的“工厂服务”，由调用方在运行时传参。
- 在
services.yaml中定义一个工厂服务，其 class 是Closure，factory 指向一个静态方法，该方法返回一个接受参数的闭包 - 例如：
app.dynamic_service_factory: factory: ['AppFactoryDynamicServiceFactory', 'forContext'] - 实际使用时：
$factory = $container->get('app.dynamic_service_factory'); $service = $factory('payment_gateway', 'stripe'); - 注意：这种模式绕过了自动装配和类型安全，适合低频、高灵活性场景，不宜滥用
用参数占位符 + 表达式语言（ExpressionLanguage）延迟解析
当参数是容器中其他服务的属性、环境变量或简单表达式结果时，可用 Symfony 内置的表达式语法实现“惰性求值”。
- 启用表达式功能：
framework.expressions: true - 在工厂调用中使用
service(...)或parameter(...)函数，例如：factory: ['AppServiceConfigurableFactory', 'build']，参数设为"@=service('request_stack').getCurrentRequest().get('mode')" - 该表达式在每次获取服务时执行，支持运行时变化，但性能略低于纯 PHP 编译方案
避免常见误区
动态不等于随意。以下做法会破坏容器设计原则，应规避：
- 在工厂构造函数里直接注入整个
ContainerInterface并手动get()—— 这是 Service Locator 反模式，损害可测性与透明性 - 把工厂方法设计成接受任意字符串并反射创建类 —— 失去类型提示、IDE 支持和静态分析能力
- 在
__invoke方法中做复杂逻辑分支 —— 应拆分为多个明确职责的专用工厂或策略服务
