Apache的SetEnv变量必须在请求进入PHP前由Apache主动注入，否则getenv()和$_SERVER均无法获取；它仅对当前作用域生效，且不修改系统环境或影响PHP-FPM启动环境。
Apache 环境变量必须在请求进入 PHP 之前由 Apache 主动注入，否则 getenv()、$_SERVER 都拿不到——这是绝大多数人读不到变量的根本原因。
Apache 配置中用 SetEnv 设置变量（推荐）
在 Apache 的虚拟主机配置（如 httpd-vhosts.conf）或目录级配置（如 .htaccess）中，直接使用 SetEnv 指令：
SetEnv APP_ENV production SetEnv DB_HOST 127.0.0.1
注意：SetEnv 只对当前作用域生效（比如某个 <virtualhost></virtualhost> 或某个目录），且仅在 Apache 处理请求时注入到 CGI/FCGI 环境中。它不修改系统级环境变量，也不影响 PHP-FPM 进程启动时的环境。
- 若用
.htaccess，需确保 Apache 已启用AllowOverride All且mod_env已加载 - Windows 下某些 Apache 版本对
SetEnv值含空格或特殊字符支持不稳定，建议避免空格和引号 - 该方式设置的变量会自动出现在
$_SERVER中，但不会写入$_ENV（除非php.ini的variables_order包含E）
PHP 中读取 Apache 注入的变量：优先用 getenv()，别依赖 $_ENV
getenv("APP_ENV") 是最可靠的方式，它绕过 PHP 的超全局数组填充逻辑，直接查 Apache 传入的环境块。而 $_ENV["APP_ENV"] 是否可用，取决于 php.ini 中的 variables_order = "EGPCS" —— 如果漏了 E，$_ENV 就是空数组。
立即学习“PHP免费学习笔记（深入）”；
-
$_SERVER["APP_ENV"]通常能拿到（SetEnv注入后自动映射），但命名冲突风险高（比如和 Apache 自带的SERVER_NAME同名） -
getenv()返回false表示未设置，不是空字符串，判断时别用== ""，要用=== false - CLI 模式下运行脚本（如
php test.php）完全不走 Apache，SetEnv变量不可见
php-fpm.conf 中设 env[XXX] 不等于 Apache SetEnv
如果你在 php-fpm.conf 的 pool 段里写了 env[APP_ENV] = staging，这只会注入到 PHP-FPM 子进程的初始环境，和 Apache 的 SetEnv 是两套机制。它们可能共存，但来源不同、作用时机不同：
- Apache
SetEnv：每次 HTTP 请求时注入，可动态 per-vhost / per-dir - php-fpm
env[...]：PHP-FPM 启动时一次性注入，所有请求共享，重启服务才更新 - 两者都生效时，
getenv()读到的是最后覆盖的那个值（通常 php-fpm 的值会被 Apache 覆盖，取决于 FastCGI 协议传递顺序）
常见失败场景和验证方法
变量“设置了但读不到”，八成卡在这几个环节：
- Apache 配置改完没重启：
sudo apachectl restart或systemctl restart apache2 - 用了
apache_setenv()函数：它只影响 Apache 子进程内部，不透传给 PHP，且已废弃，PHP 8+ 移除 - 在 Nginx + PHP-FPM 架构下误用
SetEnv：Nginx 不支持该指令，得用fastcgi_param APP_ENV production; - 验证是否生效：在 PHP 脚本里加一行
var_dump(array_keys($_SERVER));，看输出里有没有你的变量名
真正关键的不是“怎么写”，而是确认变量从哪来、经过哪层、被谁覆盖——Apache 环境变量的生命周期很短，只活在一次请求的 FastCGI 通信中，离开这个上下文就不存在了。
