Symfony中应通过DI容器注入环境变量（如%env(APP_ENV)%），而非直接读$_SERVER或$_ENV，因后者依赖Dotenv加载时机且易被覆盖。
直接读 $_SERVER 会漏掉 .env 里定义的变量
Symfony 启动时会把 .env 文件里的键值对加载进 $_ENV 和 $_SERVER，但前提是 Dotenv 组件已启用且未被跳过。如果你在 public/index.php 或命令行中直接访问 $_SERVER['APP_ENV']，它可能为空——因为 Dotenv::bootEnv() 还没执行，或者你用了 --no-env 启动。
- 检查
public/index.php是否包含Dotenv::bootEnv(dirname(__DIR__).'/.env'); - CLI 命令默认加载
.env，但加了--no-env就不会加载 -
$_SERVER是 PHP 超全局变量，会被 Web 服务器（如 Apache/Nginx）或 CLI 环境预先写入，和.env无必然关系 - 真正可靠的方式是走 Symfony 的容器：用
%env(APP_ENV)%占位符或$_ENV（Dotenv加载后才可用）
在服务/控制器里安全读取环境变量要用 %env(...)% 占位符
Symfony 推荐方式不是手动查 $_ENV 或 $_SERVER，而是让 DI 容器在编译期注入。这样既支持缓存，又能自动处理类型转换、默认值和加密变量（如 %env(base64:SECRET_KEY)%）。
- 在
config/services.yaml中写：app.debug_mode: '%env(bool:DEBUG_MODE)%' - 在构造函数参数中用类型提示：
public function __construct(private bool $debugMode) {} - 若变量未定义且无默认值，容器编译会报错：
The environment variable "DEBUG_MODE" is not defined - 避免在运行时用
getenv('APP_ENV')—— 它不走 Symfony 的解析链，无法触发resolve:、default:等修饰符
$_ENV 和 $_SERVER 在 Symfony 中的差异很实际
加载 .env 后，Dotenv 默认把变量同时写入 $_ENV 和 $_SERVER。但 Web 服务器可能覆盖 $_SERVER，而 $_ENV 更干净、更可控。
-
$_SERVER['APP_ENV']可能被 Apache 的SetEnv或 Nginx 的fastcgi_param覆盖，导致和.env不一致 -
$_ENV['APP_ENV']只来自Dotenv加载结果（除非你手动改过），更可信 - PHP 配置项
variables_order若不含E，$_ENV就不可用；现代 Symfony 要求它必须开启 - 在测试或 CLI 场景下，
$_ENV是最稳定的选择，比如var_dump($_ENV['DATABASE_URL'] ?? 'missing');
本地开发时 .env.local 优先级最高，但别提交到 Git
.env.local 会覆盖 .env 和 .env.dist，适合存数据库密码、API 密钥等敏感值。但它不会被 Symfony 自动加载进 $_SERVER —— 加载逻辑只认 .env（或你传给 bootEnv() 的路径）。
- 确保
Dotenv::bootEnv()的路径指向包含.env.local的目录（默认就是） -
.env.local文件权限应为600，防止被 Web 服务器直接返回 - Git 忽略它：
echo ".env.local" >> .gitignore，否则密钥泄露风险极高 - 如果
.env.local存在但变量没生效，先运行php bin/console debug:container --env-var=APP_ENV确认是否被识别
.env 文件可能根本不存在，全靠外部注入 —— 这时候硬依赖 $_ENV 或 $_SERVER 就容易出问题。 
