symfony仅支持dev、prod、test三种预定义环境，新增环境名（如staging）会因配置路径缺失和容器编译器不识别而报错；正确做法是复用prod环境，通过app_stage等变量和条件化yaml配置实现差异化。
Symfony 不支持“创建新环境”这种操作——你只能使用框架预定义的环境（dev、prod、test），或通过修改 APP_ENV 值来切换行为。所谓“自定义环境”，本质是复用现有环境并调整其配置，而非新增一个独立环境类型。
为什么不能新增环境名（比如 staging）？
Symfony 的环境加载机制硬编码了三类环境：只有 dev、prod、test 能触发对应目录下的配置加载（如 config/packages/dev/）。如果你设 APP_ENV=staging，框架会尝试加载 config/packages/staging/，但该目录不存在，且容器编译器不会识别它为合法环境，最终报错：The "staging" environment is not supported.
- 环境名不是自由字符串，而是 Symfony 容器构建流程中的标识符
-
Kernel::getEnvironment()返回值必须是预设三者之一，否则Kernel::configureContainer()无法匹配到对应配置路径 - 即使你手动建了
config/packages/staging/目录，cache:clear也会失败，因为CacheWarmer不知道如何处理它
正确做法：用 prod 环境 + 配置分层模拟 staging
实际项目中，staging 或 qa 应该是 prod 的变体，而不是新环境。所有差异应通过配置文件和环境变量体现：
- 保持
APP_ENV=prod不变，避免破坏框架生命周期 - 在
.env中设置区分标识：APP_STAGE=staging - 在
config/packages/prod/下新建staging.yaml，用条件加载：when@staging: framework: csrf_protection: false - 或更推荐：用环境变量驱动配置，在
services.yaml中写：$isStaging: '%env(bool:APP_STAGE_STAGING)%'，再在构造函数或参数中使用
配置差异必须在编译期生效，不能靠运行时判断
别在服务里写 if ($_ENV['APP_STAGE'] === 'staging') —— 这会让容器失去可缓存性，且绕过 Symfony 的配置优化机制。所有分支逻辑必须落在 YAML 条件块或 %env()% 表达式里：
-
%env(bool:APP_DEBUG)%→ 自动转为布尔值，可用于开关日志级别 -
%env(resolve:DATABASE_URL)%→ 确保变量被读取，而非字面量 - 不要用
getenv('APP_STAGE')在服务构造函数里做分支，这会导致服务无法被静态分析和预编译
真正容易被忽略的是：环境变量是否在容器编译前就已可用。如果用 Docker 启动时才注入 APP_STAGE，但 cache:warmup 是构建镜像时执行的，那变量根本没生效。务必确认变量注入时机与缓存生成阶段一致。
