$_SERVER 中真正来自系统环境的键名极少，仅限 Web 服务器显式透传的变量（如 PHP-FPM 配置 env[VAR]=value 或 Apache 的 SetEnv + PassEnv），常见如 PATH、HOME 等标准变量；其余多数为 CGI/HTTP 请求信息，并非操作系统级环境变量。
$_SERVER 里哪些键名才是真正的环境变量
PHP 的 $_SERVER 数组并不全等于操作系统级的环境变量，它混杂了 CGI 协议传递的请求信息（如 REQUEST_URI、HTTP_USER_AGENT）和真正由 shell 或 systemd 注入的环境变量（如 PATH、HOME）。只有以大写字母+下划线命名、且未被 Web 服务器过滤的项才可能来自系统环境。Apache 默认会 strip 掉非标准环境变量，Nginx + PHP-FPM 则需显式配置 env 指令才能透传。
验证方法很简单：
print_r(array_filter($_SERVER, function($k) {
return ctype_upper($k[0] ?? '') && strpos($k, '_') !== false;
}, ARRAY_FILTER_USE_KEY));但注意：这仍不保证是“原始环境变量”，只是命名风格匹配。
getenv() 和 $_ENV 都不可靠，优先用 getenv('VAR', true)
$_ENV 在大多数现代 PHP 配置中默认为空数组，因为 variables_order ini 设置通常不含 E；而裸调 getenv('VAR') 在 PHP 8.1+ 会触发弃用警告，且在 CLI 和 FPM 下行为不一致——FPM 下默认禁用 getenv() 对非白名单变量的访问。
安全可靠的做法是：
- 始终使用
getenv('MY_VAR', true)（第二个参数强制从原生环境读取） - 确保 PHP-FPM pool 配置中包含
env[MY_VAR] = value或全局env[MY_VAR] - Apache 用户需在
VirtualHost或.htaccess中用SetEnv MY_VAR value，并确认PassEnv MY_VAR已启用
调试时别只看 phpinfo()，要对比 shell 输出
phpinfo() 显示的 “Environment” 区块只反映 PHP 进程启动时捕获的快照，无法体现运行时动态修改（比如 putenv()），也不显示被 Web 服务器截断的变量。真实环境变量应以 shell 命令为准：
- 查 PHP-FPM 进程实际继承的环境：
cat /proc/$(pgrep php-fpm)/environ | tr '\0' '\n' | grep MY_VAR - 查 Apache 子进程：
cat /proc/$(pgrep apache2 | head -1)/environ | tr '\0' '\n' - CLI 下直接运行
env | grep MY_VAR，再对比php -r "echo getenv('MY_VAR', true);"
常见坑：Docker 容器中 docker run -e VAR=value 设置的变量，在 exec 进入后可见，但若 PHP-FPM 是通过 supervisord 启动，还需在 supervisord 配置中加 environment=VAR="value"，否则子进程拿不到。
立即学习“PHP免费学习笔记（深入）”；
敏感变量不要硬编码，用 .env + vlucas/phpdotenv
开发阶段本地调试用 .env 文件最灵活，但生产环境严禁直接加载——vlucas/phpdotenv 默认不处理 $_SERVER 冲突，且 putenv() 修改对已加载的 $_SERVER 无效。正确姿势是：
- 在入口文件最顶部（
index.php或public/index.php）加载 dotenv：$dotenv = Dotenv\Dotenv::createImmutable(__DIR__.'/..');→$dotenv->load(); - 禁止在框架中间件或路由逻辑里再 load，避免重复覆盖
- 用
$_ENV['DB_HOST']或getenv('DB_HOST')读取，而非$_SERVER['DB_HOST']—— 因为 dotenv 默认写入$_ENV而非$_SERVER
记住：环境变量不是配置文件的替代品，它的边界很清晰——只该承载部署时差异项（host/port/token），不该塞进业务逻辑开关或长文本模板。
