symfony 7 默认不自动加载.env文件，必须在public/index.php或bin/console开头显式调用dotenv::loadenv()，且仅当app_env=dev或test时才启用，prod环境禁用以保障安全。
Symfony 7 不再自动加载 .env 文件 —— 你必须显式启用 Dotenv，否则 APP_ENV、DATABASE_URL 等变量根本不会生效。
为什么 .env 文件没被读取？
Symfony 7 默认跳过 .env 加载，这是为生产安全做的硬性限制。它只在 APP_ENV=dev 或 APP_ENV=test 时才尝试加载，且前提是入口文件中调用了 Dotenv。
- 检查
public/index.php：必须有$dotenv = new \Symfony\Component\Dotenv\Dotenv(); $dotenv->loadEnv(__DIR__.'/../.env'); - 若使用 CLI（如
bin/console），同样要在该文件开头加这段代码 - 如果项目是从旧版本升级而来，
Dotenv可能已被注释或删掉 —— 这是最常见的“变量不生效”原因 -
APP_ENV=prod下默认禁止加载.env，哪怕文件存在也不会读；生产环境应通过系统级环境变量设置，而非依赖文件
.env 文件的加载顺序和覆盖规则
Symfony 按固定优先级合并环境变量，后加载的会覆盖前面的。顺序错一个，就可能让本地调试连上生产数据库。
- 基础层：
.env（所有默认值，可提交到 Git） - 本地覆盖：
.env.local（不应提交，用于开发机个性化配置） - 环境专属：
.env.<code>APP_ENV（如.env.dev，仅当APP_ENV=dev时加载） - 环境+本地：
.env.<code>APP_ENV.local（如.env.prod.local，最高优先级） - 注意：
.env.local会覆盖.env.dev中同名变量 —— 这不是 bug，是设计行为
如何验证当前生效的环境变量？
别靠猜，用命令直接看最终解析结果。尤其在 CI/CD 或 Docker 部署中，php bin/console debug:container --env-vars 是唯一可信依据。
- 运行
php bin/console debug:container --env-vars | grep DATABASE_URL，确认输出的是你预期的连接串 - 如果输出为空或值不对，说明
Dotenv没启用，或.env路径写错了（比如少了个..） - 在 Docker 中，
APP_ENV必须通过environment:或env_file:显式传入，不能指望容器内自动读取宿主机.env - 敏感变量如
MAILER_DSN在prod环境下必须由服务器环境变量提供，.env.prod文件本身不应部署到生产机
常见陷阱：URL 特殊字符未编码、localhost 导致测试失败
数据库密码含 @、/、: 时，DATABASE_URL 会解析失败；测试环境用 localhost 可能走 Unix socket，而 Doctrine 强制 TCP。
- 密码
pa@ss/word必须写成pa%40ss%2Fword（用rawurlencode()处理） - 测试环境推荐用
127.0.0.1替代localhost，避免 MySQL socket 连接歧义 - PHP 的
getenv()在某些 SAPI（如 Apache mod_php）下不可靠，始终通过配置层引用，例如%env(DATABASE_URL)%而非直接$_ENV['DATABASE_URL'] - Doctrine 配置里不要写死
url，保持url: '%env(DATABASE_URL)%'即可 —— 多环境切换全靠这个变量驱动
最易被忽略的一点：Symfony 7 的 Dotenv 默认禁用递归加载，.env 里不能用 $(VAR) 或 ${VAR} 引用其他变量，否则会静默失败。需要变量组合时，必须在服务器环境变量层面完成拼接。
