PHP CLI 环境变量为何和 FPM 不一致：php.ini、pool 配置与运行时核对

本地终端里 php -r 'echo getenv("APP_MODE");' 能打印 production，同一台机器上的 PHP-FPM 页面却拿到空字符串，这类问题通常不是 PHP 随机丢变量，而是两个请求走了不同的 SAPI 和配置链路。先把 CLI、FPM worker、Nginx/PHP-FPM 之间的边界分开，再决定变量应该放在 pool、服务管理器还是应用配置里，定位会快很多。

先确认：你比较的不是同一个 PHP 进程

CLI 命令由当前 Shell 启动，通常调用的是命令行 SAPI；网站请求则由 Nginx 或 Apache 转给常驻的 PHP-FPM worker。即使二者都显示 PHP 8.5，启动方式、主配置文件、附加扫描目录和进程环境仍可能不同。

# CLI 侧先记录实际配置
php --ini
php -r 'echo PHP_VERSION, PHP_EOL, php_sapi_name(), PHP_EOL;'
php -r 'var_export(getenv("APP_MODE")); echo PHP_EOL;'

Web 侧不要直接打印完整环境。临时诊断可以只输出这些不敏感信息：

如果 sapi、ini 或变量状态不同，先不要改业务代码。这个结果已经说明问题出在启动链路，而不是某个控制器的条件判断逻辑。

php.ini 相同，也可能被 FPM pool 清掉

FPM 的 pool 配置有一个容易被忽略的边界：worker 启动时是否保留父进程环境。常见 pool 文件位于 /etc/php/8.5/fpm/pool.d/www.conf 或对应发行版的配置目录，实际位置以你本地的服务配置为准。

[www]
; 生产环境常见的显式边界
clear_env = yes
env[APP_MODE] = production
env[APP_REGION] = cn-east-1

clear_env = yes 并不等于 FPM 完全不能使用环境变量，而是要求你把需要传给 worker 的变量明确列出来。这样做的好处是变量白名单可审查，坏处是新增变量后必须同步修改 pool 配置。

如果变量来自 systemd、容器编排或启动脚本，只在 Shell 里 export APP_MODE=production，不代表已经进入 FPM worker。FPM 是由服务管理器启动的独立进程，不能假定它继承了你的交互式终端环境。

按这张表逐层核对，避免一上来重启整台机器

核对顺序很重要：先读实际运行值，再看对应配置，最后执行重载。只看某个配置文件的本地内容，无法证明当前正在运行的 worker 已经加载了它。

改动与回滚：只重载对应 FPM 实例

确认 pool 文件后，先保存原文件再修改，改完先检查配置语法。不同发行版的命令名可能是 php-fpm8.5、php8.5-fpm 或 php-fpm，不要盲目照搬网上的服务名。

# 示例：先做配置检查，再重载
sudo php-fpm8.5 -t
sudo systemctl reload php8.5-fpm
systemctl status php8.5-fpm --no-pager

如果重载后 Web 仍读不到变量，回看 FPM 错误日志和实际 pool 文件路径。若新配置导致 worker 无法启动，立即恢复备份配置并重新做语法检查；不要在业务代码里增加“读不到就使用默认密钥”的兜底逻辑，这会把配置故障变成更难发现的安全问题。

生产环境的三个边界别混用

普通开关可以进入 pool 白名单

例如 APP_MODE、APP_REGION 这类非秘密开关，适合显式写进 pool 或服务环境，并在应用启动时校验允许取值范围。

密钥不要通过公开诊断页验证

验证密钥时只比较是否存在、长度和不可逆摘要的前几位；诊断页用完立即删除或限制仅内网可访问。日志也不要记录完整的密钥值。

配置中心与进程环境要有唯一来源

如果应用已经从配置中心读取数据库密码，就不要再让同一个键同时由 Nginx、FPM pool 和代码默认值决定。多来源覆盖会让一次重载变成隐蔽的配置漂移问题。

常见问题

为什么 CLI 能读到变量，FPM 却是空值？

最常见原因是 CLI 和 FPM 使用了不同的启动环境，或 FPM 的 clear_env 清理了未列入 env[...] 的变量。

改了 pool 配置后必须重启 PHP-FPM 吗？

通常应先做配置语法检查，再重载对应服务，让新 worker 读取配置；如果发行版不支持平滑重载，再按服务文档选择重启操作。

可以把所有环境变量都写进 env 配置吗？

不建议。白名单越小越容易审计，密钥还应优先交给专门的秘密管理方案，避免在诊断输出和错误日志中泄露。

怎么确认 Web 请求已经换成新 worker？

在受保护的临时诊断中查看加载的 ini 路径、FPM 进程启动时间或版本标识，并完成一次真实业务请求；验证后立即移除诊断入口。

这类差异的关键不是“再加一行 getenv”，而是把变量从 Shell、服务管理器、FPM pool 到 PHP 代码的传递链路逐段验明。先确认 SAPI 和 ini，再处理 pool 白名单，最后做一次 Web/CLI 双向复查，问题通常能在一次配置变更内收敛。