debug:dotenv 是验证 symfony 环境变量加载与解析的最直接命令，它仅检查当前 cli 环境下哪些 .env 文件被读取、变量是否展开、是否存在语法错误；若返回“no environment file loaded”，根本原因是 app_env 未提前设置或设置晚于 loadenv() 执行时机；unresolved 表示 %env(resolve:var)% 中的 var 未在已加载的 .env 文件中定义或命名非法（如含 . 或 -）。
debug:dotenv 是验证 Symfony 环境变量是否被正确加载和解析的最直接命令，它不运行应用、不改配置，只告诉你「当前 CLI 环境下，.env 文件到底读了哪些、值有没有被展开、有没有语法错误」。
为什么 debug:dotenv 返回空或提示未加载任何文件
常见现象是执行 php bin/console debug:dotenv 后只显示「No environment file loaded」，但你明明有 .env 和 .env.local。根本原因只有一个：APP_ENV 没设，或设得晚于 Dotenv 加载时机。
- Symfony 的
loadEnv()（在config/bootstrap.php中调用）会根据当前$_SERVER['APP_ENV']或getenv('APP_ENV')决定要不要加载.env.$APP_ENV和.env.$APP_ENV.local - 如果 CLI 下没提前设
APP_ENV，默认是dev，但它可能被.env里其他行覆盖（比如你写了APP_ENV=prod但位置靠后），而loadEnv()已经按初始值跑完了 - 验证方式：先在终端运行
echo $APP_ENV；再运行php -r "var_dump(getenv('APP_ENV'));"—— 两者必须一致且非空
debug:dotenv 输出中看到 unresolved 是什么意思
输出里出现类似 DATABASE_URL: %env(resolve:DATABASE_URL)% (unresolved)，说明该变量在 YAML 配置中用了 %env(resolve:...)% 语法，但对应环境变量本身没定义，或定义在未被加载的 .env 文件里。
- 检查
.env或.env.local是否真包含DATABASE_URL=...行，且没有拼写错误（如多空格、漏等号、引号不闭合） - 确认该文件没被
gitignore意外排除，或权限为只读导致读取失败 - 若变量来自系统级环境（如服务器
export DATABASE_URL=...），debug:dotenv不会显示它 —— 它只管 Dotenv 解析的文件，不查全局$_ENV - 注意：裸写
%env(DATABASE_URL)%（无resolve:）永远是 unresolved，这是预期行为，不是错误
生产环境运行 debug:dotenv 报错「Dotenv is not available」
因为线上部署时通常已执行过 php bin/console dotenv:dump --format=php --env=prod，生成了 .env.local.php，并移除了所有 .env.* 文本文件。此时 Dotenv 组件本身被自动禁用（composer install --no-dev 时不会装 symfony/dotenv）。
- 不要在生产服务器上临时
composer require symfony/dotenv—— 这会破坏预编译逻辑，且引入不必要的依赖 - 真正该看的是
php bin/console debug:config framework或debug:container --env-var=DATABASE_URL，它们读的是最终生效的容器参数，而非原始 .env - 如果非要确认变量值，直接
php -r "var_dump($_ENV['DATABASE_URL'] ?? 'not set');"更可靠
最容易被忽略的一点：.env 文件里的变量名不能含点（.）或连字符（-），像 API.KEY=xxx 或 DB-URL=xxx 会导致解析失败且 debug:dotenv 不报错 —— 它静默跳过，只加载合法变量。这类命名在 PHP 超全局数组里也拿不到，别指望后续配置能引用它。
