PHP命令行全局调用依赖PATH环境变量，而getenv()读取环境变量需配置php.ini中variables_order="EGPCS"并重启服务，Web请求还需通过Apache/Nginx/FPM单独传递环境变量。
PHP 命令行能全局调用，靠的是系统 PATH 环境变量；而 PHP 脚本里能读到 getenv('APP_ENV')，靠的却是操作系统级环境变量本身——这两者不是一回事，但常被混为一谈。配置错一个，php -v 会失败；配置错另一个，$_ENV 就是空数组。
怎么让 php 命令在任意目录下都能运行
这是最基础也最容易卡住的一步：确保终端能识别 php 这个命令。
- 先确认
php.exe（Windows）或php（macOS/Linux）的真实路径，比如C:\php或/usr/local/bin/php；用where php（Windows）或which php（macOS/Linux）验证 - Windows 下编辑系统
Path变量时，**必须点“新建”添加整条路径**（如C:\php），不要手敲进已有值里拼接，避免分号遗漏或路径末尾多斜杠 - macOS/Linux 用户注意 shell 类型：
zsh用户改~/.zshrc，bash用户改~/.bash_profile，改完必须执行source ~/.zshrc - 改完一定要**新开一个终端窗口**再测试，旧窗口不会自动重载
PATH
验证命令：php -v 成功返回版本号才算过关。
为什么 getenv() 返回 false，但 $_ENV 是空的
这和 php.ini 的 variables_order 设置强相关，不是环境变量没设，而是 PHP 拒绝加载它。
立即学习“PHP免费学习笔记（深入）”；
- 打开你的
php.ini文件，搜索variables_order，默认值通常是"GPCS"—— 里面没有E，所以环境变量根本不会进$_ENV - 改成
variables_order = "EGPCS"（把E放最前，确保优先加载环境变量） - 同时检查
register_argc_argv = On，某些 CLI 场景下它影响$_SERVER['argv']，间接干扰环境变量可见性 - 改完必须重启 Web 服务器（Apache/Nginx）或 PHP-FPM 进程，仅重启网页不生效
之后再用 getenv('SOME_VAR') 或 $_ENV['SOME_VAR'] 才可能拿到值。
如何在 Web 请求中安全传入 APP_ENV=prod
CLI 下设的环境变量（如 export APP_ENV=prod）对 Web 请求无效——Apache/Nginx 不会自动把 Shell 环境变量透传给 PHP 子进程。
- Apache 用户：在
.htaccess或虚拟主机配置里加SetEnv APP_ENV prod - Nginx 用户：在
server或location块里加fastcgi_param APP_ENV prod; - PHP-FPM 用户：直接在池配置（如
www.conf）里写env[APP_ENV] = prod - 绝对不要在 PHP 脚本里用
putenv('APP_ENV=prod')来模拟——它只对当前请求有效，且无法覆盖 FPM 已加载的变量
这类设置方式才能确保每个 HTTP 请求启动的 PHP 进程都携带一致的环境标识。
PHPRC 和 PHP_INI_SCAN_DIR 是干什么的
它们不参与“运行时环境变量”，但直接影响 php.ini 加载行为，间接决定 getenv() 是否可用。
-
PHPRC指定具体php.ini文件路径，例如PHPRC=C:\myapp\php.ini，绕过默认查找逻辑 -
PHP_INI_SCAN_DIR指向一个目录，PHP 会自动加载该目录下所有.ini文件（如扩展配置），适合分离主配置与环境适配项 - 这两个变量本身也要通过系统环境变量设置（Windows 在“环境变量”界面添加，Linux/macOS 写入 shell 配置），且必须在 PHP 启动前就存在
- 常见坑：设了
PHPRC却忘了把variables_order复制进新php.ini，结果还是读不到环境变量
真正容易被忽略的是：Web 服务器和 CLI 使用的可能是两套 php.ini（php --ini 和 phpinfo() 显示路径常不同），环境变量行为也会因此分裂。
