Symfony中不存在“合成服务”官方概念，实际需求对应装饰器增强、工厂动态构造、表达式条件选择三种机制，应避免手动new实例或控制器内组装等反模式。
Symfony 中没有“合成服务”这个官方术语，它通常是对服务装饰（Service Decoration）或工厂服务 + 动态参数注入的误称或口语化表达。实际开发中，真正需要的不是“合成”，而是组合行为、复用逻辑、按需构造实例——这对应 Symfony 官方支持的几种成熟机制。
用装饰器（Decorate）增强现有服务
当你想在不修改原始服务的前提下，为其添加日志、缓存、权限校验等横切逻辑时，装饰是最标准的做法：
- 创建一个新类（如
App\Service\CachedMailer），实现与被装饰服务相同的接口（如MailerInterface） - 构造函数接收原服务（
$decorated）和额外依赖（如CacheInterface） - 在
config/services.yaml中声明：App\Service\CachedMailer: decorates: 'mailer.default' decoration_inner_name: 'cached_mailer.inner' arguments: $decorated: '@cached_mailer.inner' $cache: '@cache.app' - 调用
MailerInterface时，容器自动返回你的装饰器实例，原始服务可通过$decorated访问
用工厂服务动态构造实例
当服务初始化依赖运行时数据（如数据库配置、租户ID、请求上下文），应封装为工厂：
- 定义工厂类（如
App\Factory\TenantConnectionFactory），含静态或实例方法（如createForTenant(string $id)） - 在
services.yaml中注册工厂本身为服务，并配置目标服务使用该工厂：App\Factory\TenantConnectionFactory: ~ App\Connection\TenantConnection: factory: ['@App\Factory\TenantConnectionFactory', 'createForTenant'] arguments: ["%tenant.id%"]
- 若
%tenant.id%是动态值（如来自请求头），可改用 编译器 Pass 或 表达式语言 注入：arguments: ["service('request_stack').getCurrentRequest().headers.get('X-Tenant-ID')"]
用表达式语言实现条件化服务选择
当需要根据环境、参数或运行时状态切换服务实现时，表达式语言比硬编码更灵活：
- 在
services.yaml中直接写逻辑：App\Service\PaymentProcessor: class: '%env(bool:USE_STRIPE_GATEWAY)%' ? 'App\Service\StripeProcessor' : 'App\Service\PayPalProcessor'
- 或结合
service()函数做更复杂判断：App\Service\Notifier: arguments: $mailer: "@= service('kernel.environment') == 'prod' ? service('mailer.sendgrid') : service('mailer.dev') - 注意：表达式在容器编译期求值，不能访问未注册服务或未解析参数
避免常见误区
所谓“合成服务”，常源于对容器机制的误解：
- 不要手动 new 实例再 set 进容器：破坏 DI 原则，无法享受自动注入、作用域管理、装饰链等特性
-
不要滥用
_controller或字符串服务 ID 拼接：这不是服务合成，是反模式，易引发不可控的类加载和安全风险 - 不要在控制器里“组装”多个服务返回一个临时对象：应提取为独立服务类，由容器统一管理生命周期
- 动态服务 ≠ 运行时随意 new 对象，而是通过容器可控地构造、修饰、选择
