getenv() 返回 false 因变量未注入进程、大小写错误或 Web 服务器未传递；$_ENV 为空因 php.ini 的 variables_order 缺少 E；可靠设置需用 PHP-FPM env[]、Nginx fastcgi_param 或 Docker environment。
直接用 getenv() 就行，但得知道它在什么情况下会返回 false、为什么有时 $_ENV['FOO'] 是空的、以及哪些场景下必须配合 Web 服务器或 PHP-FPM 配置才真正可靠。
getenv() 为什么有时返回 false
getenv() 不是“读不到就报错”，而是“查不到就返回 false”。常见原因有：
- 变量根本没被注入到当前 PHP 进程的环境里（比如只在 shell 里
export FOO=bar，但没重启 PHP-FPM） - 变量名大小写不一致（Linux 下
FOO和foo是两个变量） - PHP 运行在 CGI/FastCGI 模式下，且 Web 服务器未显式传递该变量（如 Nginx 默认不传）
- CLI 脚本里能读到，Web 请求里读不到——这是典型的作用域隔离，不是函数问题
$_ENV 为空？先看 php.ini 的 variables_order
$_ENV 是否填充，完全取决于 php.ini 中的 variables_order 配置。默认值通常是 "GPCS"（GET/POST/Cookie/Server），不含 E（Environment）。所以即使系统有 APP_ENV=prod，$_ENV['APP_ENV'] 也可能是空数组。
要让它生效，必须改配置：
- 编辑
php.ini，把variables_order = "EGPCS"（注意E在最前或中间都行） - 或者只针对 FPM：在
php-fpm.conf的 pool 段加env[APP_ENV] = prod，这样不依赖variables_order - 改完记得重启 PHP-FPM 或 Web 服务，否则无效
putenv() 设置的变量只活到脚本结束
putenv("DEBUG=true") 确实能立刻让后续的 getenv("DEBUG") 返回 "true"，但它有硬限制：
- 仅对当前请求生命周期有效，不影响其他请求、不持久化
- 不会写入
$_ENV（除非variables_order含E且 PHP 版本 ≥ 7.1，但行为不稳定，别依赖） - 无法覆盖已由 Web 服务器传递进来的同名变量（比如 Nginx 用
fastcgi_param APP_ENV "test"传了，putenv("APP_ENV=prod")通常无效） - 子进程能继承，但父进程（如 shell）完全感知不到
生产环境该在哪一层设置环境变量
真正可靠的设置位置，按优先级从高到低：
-
PHP-FPM 配置：在
www.conf或自定义 pool 文件里写env[APP_ENV] = production，启动即加载，稳定、安全、可 per-pool 控制 -
Nginx 配置：用
fastcgi_param APP_ENV "production";，确保每次请求都带，适合需要动态切换的场景（如灰度） -
Docker / 容器编排：通过
environment:或env_file:注入，和应用生命周期绑定，符合 Twelve-Factor 原则 - 系统级（/etc/environment）：仅适用于 CLI 场景或 PHP-FPM 主进程启动前加载，Web 请求中不一定可见，排查困难
绕过 Web 服务器、只靠 putenv() 或修改 .bash_profile 来“设环境变量”，在 PHP Web 应用里基本等于没设。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
