parameters.yaml用于定义全局静态参数，不可被环境文件覆盖，不支持环境变量解析；环境相关配置应通过.env文件配合%env(resolve:VAR)%在services_{env}.yaml中定义。
在 Symfony 6.4 中，parameters.yaml 是存放全局、静态配置参数的起点，但它**不是环境适配的首选方式**，也不该直接写环境变量引用。它的作用很明确：定义基础常量类参数（如应用名、默认时区），供其他 YAML 配置文件通过 %parameter_name% 占位符复用。
parameters.yaml 的定位和限制
这个文件位于 config/ 目录下，会被所有环境（dev/test/prod）无条件加载。它里面定义的参数无法被覆盖——哪怕你在 services_dev.yaml 里重写同名参数，也不会生效。所以它适合放真正“不变”的值，比如：
app.name: 'MyApp'app.timezone: 'Asia/Shanghai'mailer.from_email: 'no-reply@myapp.com'
注意：不要在这里写 %env(DATABASE_URL)%。这种写法不会触发环境变量解析，Symfony 会把它当纯字符串处理，后续服务构造时可能报类型错误。
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
怎么安全地读取环境变量？
真正需要随环境变化的配置（数据库、API 密钥、缓存地址等），应通过 .env 系列文件 + %env()% 表达式实现：
- 在
.env.local中设DATABASE_URL=sqlite:///%kernel.project_dir%/var/app.db - 在
.env.prod中设DATABASE_URL=mysql://user:pass@db:3306/myapp - 然后在
config/packages/doctrine.yaml中写：url: '%env(resolve:DATABASE_URL)%'
必须带resolve:前缀，否则不展开；可加兜底：'%env(default:sqlite:///%kernel.project_dir%/var/data.db:DATABASE_URL)%'
为什么别把参数全塞进 parameters.yaml？
一是它不支持环境区分，二是容易引发缓存陷阱。比如你改了 .env.prod 里的 REDIS_HOST，但没运行 bin/console cache:warmup --env=prod，容器仍会用旧值。而 parameters.yaml 本身又不能动态响应环境变量变更——它只是个静态映射表。
更推荐的做法：把环境相关参数直接写进 config/services_dev.yaml 或 config/services_prod.yaml 的 parameters: 块里，清晰、可控、无需额外文件管理。
