先确认APP_ENV是否真正生效，因debug:container --env-vars依赖其值加载对应.env文件；若未设或设错（如echo $APP_ENV非预期值），变量将不显示；CLI需前置设置APP_ENV=prod，Web服务器须显式传递，--env参数已弃用。
debug:container --env-vars 显示空或报错，先确认 APP_ENV 是否真正生效
这个命令依赖当前运行环境的 APP_ENV 值来决定加载哪个 .env 文件（如 .env.prod、.env.local），如果 APP_ENV 没设或设错，它就看不到你定义的变量。
在终端里直接运行：echo $APP_ENV。如果不是预期值（比如想看 prod 环境却输出 dev 或为空），命令必然漏掉对应文件里的变量。
- CLI 下运行命令时，必须前置设置：例如
APP_ENV=prod php bin/console debug:container --env-vars - Web 服务器（如 Apache/Nginx）中需显式传递
APP_ENV到 PHP 进程，不能只靠.env文件 -
--env参数已弃用，加了也无效；必须用系统级环境变量方式传入
为什么 .env 文件里的变量没出现在 --env-vars 列表里
debug:container --env-vars 只显示被 Symfony Dotenv 实际加载并注入 $_ENV / $_SERVER 的变量，不是所有 .env 行都会出现。
- 语法错误会导致整行跳过：比如漏引号（
API_KEY=sk_live_abc应为API_KEY="sk_live_abc"）、未闭合的${}、注释符#写在值中间 - 以
SYMFONY__开头的变量会被自动转成嵌套数组格式（如SYMFONY__DATABASE__HOST=localhost→$_ENV['SYMFONY']['DATABASE']['HOST']），这类变量不会列在--env-vars中 - 只在
.env.local或.env.prod.local里定义、但对应环境没激活（如APP_ENV=dev却查.env.prod.local）的变量也不会显示
如何验证 dotenv 解析是否真成功
比 --env-vars 更底层、更可靠的验证方式是直接调用 Dotenv 工具本身：
php -r "require 'vendor/autoload.php'; (new \Symfony\Component\Dotenv\Dotenv())->loadEnv(__DIR__.'/.env'); var_dump(\$_ENV);"
这样能看到原始加载结果，绕过容器层干扰。常见问题一眼可见：
- 输出里没有你的变量 →
.env路径错或文件权限不足 - 变量值是字符串
"${DB_HOST:-localhost}"而不是"localhost"→resolve:前缀缺失或未启用Dotenv::usePutenv(true) - 报
Dotenv::parse(): Failed to parse line ...→ 某行有不可见字符或编码问题（推荐用 UTF-8 无 BOM 编辑）
看到变量但服务里用不了？检查 %env(resolve:VAR)% 语法是否写对
debug:container --env-vars 显示变量，不代表它能被服务自动解析。关键在使用处是否加了 resolve: 前缀。
- 错：
'%env(API_TIMEOUT_MS)%'→ 容器当普通字符串处理，不读取环境变量 - 对：
'%env(resolve:API_TIMEOUT_MS)%'→ 触发 Dotenv 解析，支持int:、bool:等类型转换 - 如果变量名含点或连字符（如
REDIS.HOST或API-TIMEOUT），必须用下划线重命名后引用，Symfony 不支持原样解析这些字符 - PHP 8+ 构造函数参数自动绑定时，也要求变量名和参数名完全一致且声明了类型，否则即使
--env-vars里有，也不会注入
APP_ENV 在 CLI 和 Web 两种上下文中的不同设置方式——它们互不影响，必须分别验证。 
