cli和网页php配置不同是因为二者加载不同php.ini文件：cli读取如/etc/php/8.2/cli/php.ini，web（fpm）读取如/etc/php/8.2/fpm/php.ini，修改后需分别验证路径并重启对应服务。
CLI 和网页访问 PHP 配置不相同，是因为它们根本就不是同一个 PHP 进程，也不加载同一份配置文件。
php --ini 和 phpinfo() 显示的 php.ini 路径不同
CLI 模式下执行 php --ini，看到的是 CLI 专属的配置路径（比如 /etc/php/8.2/cli/php.ini）；而网页中调用 phpinfo()，显示的「Loaded Configuration File」通常是 FPM 或 CGI 对应的路径（比如 /etc/php/8.2/fpm/php.ini）。这两个文件内容可以完全独立，哪怕只改其中一个，另一个也不会同步生效。
- Linux 下可通过
php --ini查 CLI 配置位置，php-fpm -t && systemctl status php8.2-fpm确认当前启用的 FPM 实例版本 - Windows 下 CLI 默认可能读
C:\Windows\php.ini，而 FPM 读的是C:\php\php.ini或 Nginx 配置中fastcgi_param PHP_VALUE指定的路径 - 修改后必须分别重启：CLI 不需要重启，但 FPM 必须
systemctl restart php8.2-fpm（或对应服务名）
扩展启用状态在 CLI 和 FPM 中可能不一致
有些扩展（如 xdebug、opcache、redis）默认只在某一种 SAPI 下启用。例如 xdebug 常被禁用在 FPM 中以保性能，却开在 CLI 里用于调试；反过来，opcache.enable_cli=0 是默认值，意味着 CLI 下 opcache 实际是关闭的——即使你在 php.ini 里开了 opcache.enable=1。
- 检查扩展是否加载：CLI 下运行
php -m | grep redis，FPM 下看phpinfo()页面的「Registered PHP Streams」或「Additional Modules」区块 - 扩展配置文件（如
redis.ini）可能被放在mods-available/目录下，需软链到cli/conf.d/和fpm/conf.d/两个目录才都生效 -
opcache.enable_cli是独立开关，CLI 下必须显式设为1才启用 opcache
环境变量和启动方式导致实际加载的配置被覆盖
CLI 可通过 PHP_INI_SCAN_DIR、PHPRC 等环境变量强行指定配置目录，而 Web 服务器（Nginx/Apache）可能通过 fastcgi_param PHP_VALUE "memory_limit=512M" 在请求时动态覆盖 ini 设置——这种覆盖只对当次 HTTP 请求有效，CLI 完全感知不到。
- FPM pool 配置中（如
/etc/php/8.2/fpm/pool.d/www.conf）的php_admin_value[memory_limit] = 256M会强制覆盖 php.ini 中的值，且 CLI 不读这个文件 - 某些 Docker 镜像或集成环境（如 Laragon）会把 CLI 的
php二进制替换成 wrapper 脚本，内部设置了PHPRC，导致你以为改了全局 php.ini，其实 CLI 根本没读它 - 用
php -c /path/to/custom.ini script.php可临时指定配置，但这个动作本身也说明默认配置不是你想象的那一个
最常被忽略的一点：改完配置后，你以为 reload nginx 就够了，但 FPM 进程可能还在用旧内存镜像；而 CLI 看似“立刻生效”，其实只是因为你没注意它压根就没加载你刚改的那个文件。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
