PHP如何让CLI与FPM共享库_CLI与FPM共享库做法【共用】

CLI 和 FPM 能共享扩展和配置的前提是二者加载相同的 php.ini 文件或完全一致的 extension_dir 与 extension= 配置项,且扩展文件存在、可读、ABI 兼容;需避免 php_admin_value 等运行时覆盖,并验证运行时功能而非仅模块列表。

PHP CLI 和 FPM 共享同一套扩展和配置的前提是什么

CLI 和 FPM 能

共享库,本质是因为它们用的是同一个 php.ini 文件(或加载了相同路径下的配置),且扩展是通过 extension=xxx.so(Linux/macOS)或 extension=xxx.dll(Windows)动态加载的——只要扩展文件存在、权限可读、ABI 兼容,CLI 和 FPM 都能加载它。

但默认情况下,很多系统会为 CLI 和 FPM 分别配置不同的 php.ini:比如 Ubuntu 的 /etc/php/*/cli/php.ini/etc/php/*/fpm/php.ini。这时候看似“同一 PHP 版本”,实际加载的扩展可能完全不同。

  • 检查当前 CLI 加载的配置:php --ini
  • 检查 FPM 加载的配置:在 FPM 的 www.conf 中确认 php_admin_value[php_ini] 是否被覆盖;否则看 php-fpm -tphp-fpm -i | grep "Loaded Configuration File"
  • 关键判断依据:两个 SAPI 加载的 php.ini 必须指向同一个文件,或至少确保 extension_dir 相同、extension= 行完全一致

如何让 CLI 和 FPM 真正共用 extension_dir 和扩展列表

最稳妥的做法是统一配置入口,避免双份维护。不推荐“复制粘贴 ini 文件”,而应让两者指向同一主配置。

  • 把所有自定义扩展配置(如 extension=redis.soextension=grpc.so)集中写到一个独立文件,比如 /etc/php/conf.d/99-common.ini
  • 确保 CLI 和 FPM 的主 php.ini 都启用了 scan_dir(默认开启),即包含类似 include_path = ".:/usr/share/php" 且支持 conf.d/ 扫描
  • 验证是否生效:php -m | grep redisphp-fpm -m | grep redis 输出应一致
  • 注意:某些扩展(如 opcache)在 CLI 下默认禁用(opcache.enable_cli=0),即使加载了也不起作用——这不是“没共享”,而是运行时策略不同

常见踩坑点:扩展加载成功但行为不一致

扩展 .so 文件被加载 ≠ 功能表现一致。以下情况会导致“看似共享,实则失效”:

  • extension_dir 路径不同:CLI 可能用 /usr/lib/php/20250829/,FPM 却指向 /usr/lib/php/20250902/(对应不同 PHP 主版本 ABI)——此时即使文件名一样,也会报 undefined symbol 或直接跳过加载
  • 扩展依赖的底层库版本冲突:例如 CLI 用系统 OpenSSL 3.0,FPM 被编译链接了 LibreSSL,导致 curlopenssl 扩展在某一边初始化失败(错误日志里可能只显示 Failed to load module,无细节)
  • 环境变量干扰:FPM 进程常以 www-data 用户运行,而 CLI 是当前用户;若扩展依赖 /dev/shm/tmp 下的 socket 或锁文件,权限/路径隔离会导致运行时失败(例如 apcu 的共享内存段不可见)
  • PHP-FPM 的 php_admin_flag / php_admin_value 会强制覆盖 php.ini 设置,包括 extension= ——这种覆盖是单向的,CLI 完全不受影响,极易造成“两边看到的 phpinfo() 不一样”

验证共享是否真正生效的最小检查清单

不要只看 php -m,要穿透到运行时能力:

php -r "echo extension_loaded('redis') ? 'OK' : 'MISSING';"
php-fpm -t && sudo systemctl restart php*-fpm
curl -s http://localhost/test.php | grep redis

其中 test.php 内容为:

 extension_loaded('redis'),
    'version' => phpversion('redis'),
    'class_exists' => class_exists('Redis'),
]);

如果 CLI 返回 true 而 FPM 返回 false,说明不是“没装”,而是加载路径、权限、或 php_admin_value 拦截了扩展启用。这时优先查 FPM 错误日志(tail -f /var/log/php*-fpm.log),比反复改 ini 更快定位真实原因。