Symfony推荐通过声明参数并注入使用，而非直接调用getParameter()；需在services.yaml中用'%param_name%'注入构造函数，且签名须严格匹配类型与顺序。
直接读取配置参数不是 Symfony 的推荐做法——参数必须先声明、再注入，靠 $container->getParameter() 临时捞值属于反模式，容易在缓存编译后失效或引发环境不一致。
parameters.yaml 里定义的参数怎么被服务用上
关键不是“读”，而是“传”。Symfony 的参数系统本质是容器编译期的值替换，不是运行时动态查表。
-
parameters.yaml中定义的参数（如app.upload_path: '/var/uploads'）只在容器编译时被加载一次，之后固化进缓存 - 服务要用它，必须在
config/services.yaml里显式通过arguments: ['%app.upload_path%']注入构造函数 - 构造函数签名必须严格匹配：类型提示要兼容（比如
string $uploadPath），顺序不能错，否则容器编译报Too few arguments - 不要在服务内部写
$this->container->getParameter('app.upload_path')—— 这绕过 DI，破坏可测试性，且在 prod 环境可能因缓存未更新而返回旧值
%env()% 变量为什么本地能用、部署就报错
因为 %env(FOO)% 不是运行时解析，而是在 cache:warmup 或首次 cache:clear 时展开并固化到缓存中。
- 如果部署后没执行
bin/console cache:warmup --env=prod，容器仍用上次编译时读到的环境变量值 - 漏掉
resolve:前缀（如写成'%env(FOO)%'而非'%env(resolve:FOO)%'）会导致字符串字面量，根本不会触发解析 -
.env.local文件必须存在且权限可读；.env.prod这类文件不会自动加载，得靠Dotenv::createMutable()->loadEnv(__DIR__.'/../.env.prod');手动引入（通常由 Kernel 控制） - 类型转换如
%env(int:DB_PORT)%必须搭配resolve:，否则 int 转换不生效
结构化配置（比如 theme.yaml）怎么转成 PHP 数组
这不是靠“读文件”，而是靠 Symfony Config 组件的树构建 + 扩展类处理，最终以参数形式注册进容器。
- 先在
config/packages/theme.yaml写嵌套结构，如theme.colors.primary: '#3498db' - 创建
DependencyInjection/Configuration.php，用TreeBuilder定义节点类型、默认值和验证规则（比如booleanNode('dark_mode_enabled')->defaultFalse()） - 在
DependencyInjection/ThemeExtension.php中调用$container->setParameter('theme_config', $config)，把处理后的数组塞进去 - 服务中注入时用
arguments: ['%theme_config%']，而非手动json_decode(file_get_contents()) - 别试图在控制器里用
Yaml::parseFile()直接读theme.yaml—— 这跳过验证、不支持多文件合并、无法享受环境覆盖机制
最易被忽略的一点：所有参数变更后，必须清缓存并重跑 warmup，否则改了 parameters.yaml 或 .env 也看不到效果。缓存不是辅助，它是 Symfony 配置生效的必经路径。
