symfony 4 中应通过容器条件加载实现环境适配：用服务别名绑定接口到环境专属实现，或用参数驱动工厂服务，或按环境加载专属配置文件；避免在服务内硬编码环境判断。
在 Symfony 4 中，实现“同一服务接口、不同环境使用不同实现”，核心是利用容器的条件加载机制和环境感知配置，而不是硬编码判断 $_SERVER['APP_ENV'] 或在服务逻辑里写 if-else。
用服务别名 + 条件服务定义
这是最推荐、最符合 Symfony 设计哲学的方式。你定义一个统一的服务 ID（如 App\Service\PaymentProcessor），再根据当前环境绑定到具体实现类。
- 在
config/services.yaml中声明接口别名：
services:
App\Service\PaymentProcessorInterface: '@app.payment_processor.%env(APP_ENV)%'
然后为每个环境提供对应的具体服务定义：
-
config/packages/dev/payment.yaml：
services:
app.payment_processor.dev:
class: App\Service\Payment\SandboxProcessor
public: false
-
config/packages/prod/payment.yaml：
services:
app.payment_processor.prod:
class: App\Service\Payment\StripeProcessor
public: false
这样，无论在 dev 还是 prod 环境，只要注入 PaymentProcessorInterface，容器就会自动解析为对应环境的实现，完全透明。
用参数驱动工厂服务
适合实现逻辑差异不大、仅配置或行为开关不同的场景（比如日志级别、重试次数、是否启用缓存）。
- 定义一个工厂类，接收环境参数或配置参数；
- 在
services.yaml中通过factory和arguments控制实例化逻辑； - 例如：用
%kernel.environment%参数决定是否启用调试模式：
App\Service\AnalyticsClient:
factory: ['App\Service\AnalyticsClientFactory', 'create']
arguments:
$environment: '%kernel.environment%'
$trackingId: '%env(ANALYTICS_ID)%'
用环境专属配置文件加载不同服务
Symfony 4 默认已按环境加载 config/packages/{env}/ 下的 YAML 文件。你可以把整套服务定义拆开，只在对应环境生效。
- 例如：
config/packages/test/api_client.yaml定义一个 MockApiClient； -
config/packages/prod/api_client.yaml定义真实 HTTP 客户端； - 确保这些文件中不设
public: true，避免命名冲突； - 在主服务中通过接口依赖注入，容器会按需加载并绑定。
避免的写法
以下方式不推荐：
- 在构造函数或方法里手动检查
$this->environment === 'dev'—— 破坏单一职责，难以测试； - 用
if ($container->hasParameter('kernel.environment') && 'dev' === $container->getParameter('kernel.environment'))在服务内部做分支 —— 违反依赖倒置原则； - 把不同环境的类都注册成 public 服务，靠业务代码手动选择 —— 失去 DI 容器的价值。
关键是让容器替你决策，而不是让服务自己猜环境。
