Symfony配置管理核心是分层加载+环境感知+编译期解析，按全局配置→环境专属配置→服务定义顺序加载，环境变量需用%env(resolve:VAR)%展开，自定义加载须实现LoaderInterface，测试环境需显式启用test.service_container。
Symfony 配置管理核心在于“分层加载 + 环境感知 + 编译期解析”，不是靠文件名自动匹配，而是由加载器（Loader）按规则逐层导入、合并、编译。关键不在于“怎么写”，而在于“谁在什么时候加载了什么”。
配置加载的层级顺序很关键
框架默认按以下顺序加载（从早到晚，后加载的可覆盖前者的同名参数）：
- 全局基础配置：config/packages/*.yaml（如 framework.yaml、doctrine.yaml），所有环境都加载
- 环境专属配置：config/packages/dev.yaml、config/packages/test.yaml、config/packages/prod.yaml —— 只有对应 APP_ENV 下才生效
- 服务定义文件：config/services.yaml 是主入口，但真正区分环境的是 config/services_dev.yaml 这类文件（需手动 import 或由 Kernel 显式加载）
- 参数文件本身不自动分环境：parameters.yaml 全局加载；parameters_dev.yaml 不会被自动识别，必须在 services_dev.yaml 里用 imports: [{ resource: 'parameters_dev.yaml' }] 显式引入
环境参数不能靠文件名“猜”，得靠配置逻辑
想让 dev 环境用一套数据库配置、prod 用另一套，推荐做法是：
- 在 .env.local 中设 DATABASE_URL=sqlite:///%kernel.project_dir%/var/data.db（开发）
- 在 .env.prod 中设 DATABASE_URL=mysql://user:pass@prod-db:3306/app（生产）
- 在 config/packages/doctrine.yaml 中写 url: '%env(resolve:DATABASE_URL)%' —— resolve: 前缀确保环境变量被展开
- 避免在 parameters.yaml 里直接写 %env(DATABASE_URL)%，它会被当字符串字面量，不会触发解析
自定义配置加载要走 Loader 接口
如果要把路由、工作流或验证规则从第三方 Bundle 或数据库加载进来，必须实现 LoaderInterface：
- Bundle 的 Extension 类中，用 YamlFileLoader 加载 resources/config/*.yml
- 动态路由不能 runtime 查库，应在部署时预生成 PHP 路由文件，再用 PhpFileLoader 加载
- 自定义 Loader 必须返回 RouteCollection 实例，不能返回数组或 null
- 确保 config/packages/framework.yaml 中 router: resource 指向一个有效入口（哪怕只是空 YAML 文件），否则整个路由链可能跳过
测试环境容器要手动“激活”
单元测试里取不到私有服务？常见原因是 test.service_container 没启用：
- 在 src/Kernel.php 的 configureContainer() 方法中，显式 import services_test.php
- 确认 config/packages/test/framework.yaml 中已设 framework.test: true
- 私有服务（public: false）在编译期会被内联移除，测试中如需访问，要么设 public: true，要么在 services_test.php 中重定义为 public
- 不要依赖 static::getContainer() 默认行为，务必先 bootKernel() 并确认容器已加载测试专用配置
