不能靠环境变量“动态加载”服务，但能靠环境变量控制服务是否注册、用哪套配置、走哪个实现；因Symfony DI容器编译在请求前完成，%env(...)%仅运行时解析，故class、factory等结构字段必须静态确定，仅arguments、bind、calls等参数位置可用环境变量。
直接结论：不能靠环境变量“动态加载”服务，但能靠环境变量控制服务是否注册、用哪套配置、走哪个实现。
为什么services.yaml里写%env(APP_ENV)%不生效？
Symfony 的 DI 容器编译发生在请求之前，而 %env(...)% 是在运行时才解析的——但服务定义（比如类名、参数、是否 public）必须在编译期就确定。所以你在 services.yaml 顶层直接写 App\Service\Foo: class: '%env(MY_SERVICE_CLASS)%' 会报错：Invalid type for parameter "class"，因为容器无法在编译时推导类型。
- 环境变量只能用于参数值（
arguments、bind、calls），不能用于服务定义结构本身 -
class、factory、public、tags这些字段必须是静态可分析的字符串或引用 - 想“按环境开关服务”，得靠目录分层或条件表达式
真正有效的环境感知方式：目录结构 + 条件表达式
Symfony 8 默认支持 config/packages/{env}/ 目录自动加载。这是最稳定、最推荐的方式：
-
config/packages/dev/mailer.yaml：只在dev环境加载调试用的MockMailer -
config/packages/prod/mailer.yaml：只在prod环境加载真实的SmtpMailer - 两个文件里可以定义同一名字的服务（如
app.mailer），不会冲突，因为它们互斥加载
如果必须在一个文件里做判断，可用 when@env 条件块（Symfony 6.2+）：
services:
app.mailer:
class: App\Service\SmtpMailer
arguments: ['%env(MAILER_HOST)%']
when: '@prod'
<p>app.mailer:
class: App\Service\MockMailer
when: '@dev'注意：when 不是运行时判断，而是编译期根据当前 APP_ENV 值决定保留哪段定义。
环境变量能安全用在哪？
只在以下位置使用 %env(...)% 是安全且常见的：
-
arguments：比如数据库连接串- '%env(DATABASE_URL)%' -
bind：绑定构造参数App\Service\Foo::__construct: '$host': '%env(MAILER_HOST)%' -
calls：setter 注入- [setApiTimeout, ['%env(API_TIMEOUT)%']] -
parameters：定义全局参数后复用database.host: '%env(DATABASE_HOST)%'
别试图把 %env(...)% 放进 class 或 factory 字段——容器编译失败是必然结果。
复杂点在于跨环境的服务生命周期差异
比如 dev 下你希望 app.cache 是 ArrayAdapter（无持久化），prod 下是 RedisAdapter。这时不能只换 class，还要换依赖（Redis 连接服务）。最稳妥的做法是：把不同实现拆成独立服务，再用接口 + 别名统一出口：
services:
# dev
app.cache.array:
class: Symfony\Component\Cache\Adapter\ArrayAdapter
<h1>prod</h1><p>app.cache.redis:
class: Symfony\Component\Cache\Adapter\RedisAdapter
arguments: ['@cache.default_redis_provider']</p><h1>统一别名（根据环境自动指向）</h1><p>Psr\Cache\CacheItemPoolInterface: '@app.cache.array'
when: '@dev'</p><p>Psr\Cache\CacheItemPoolInterface: '@app.cache.redis'
when: '@prod'这种写法既清晰又可测试，也避开了运行时类型不可知的风险。最容易被忽略的是：别名覆盖必须在同一个编译上下文中完成，否则 autowire 会找不到目标接口实现。
