Loaded Configuration File为(none)说明PHP CLI未加载php.ini，需用php --ini查搜索路径，再将php.ini复制到其实际查找目录（如/usr/local/bin/），或用strace定位确切路径后放置文件。
php --ini 显示 Loaded Configuration File 为 (none) 怎么办
这说明 CLI 模式根本没读到任何 php.ini，扩展自然不会加载，php -m 里也看不到。不是扩展没装好，是 PHP 根本没去加载配置。
执行 php --ini 查看搜索路径，重点关注 “Scan for additional .ini files in” 后面的目录（比如 /usr/local/lib/php.ini 或 /usr/local/bin），再用 ls -l 确认该路径下是否存在 php.ini。常见错误是：你把 php.ini 放在了 /etc/ 下，但 CLI 实际只去 /usr/local/bin/ 扫描。
- 用
strace php -i 2>&1 | grep php.ini直接看到它到底在哪些路径尝试 open() 配置文件 - 如果扫描路径里有空格或符号链接，注意检查是否因权限或路径断裂导致跳过
- 不要直接改系统默认路径；优先复制一份
php.ini到它正在找的那个目录，比如cp /etc/php.ini /usr/local/bin/php.ini
phpinfo() 里显示的 Loaded Configuration File 和 php --ini 不一致
这是最典型的「CLI 和 FPM 配置分离」现象。FPM 加载的是启动时通过 -c 参数指定的 php.ini（或编译时默认路径），而 CLI 只认自己二进制所在目录或环境变量决定的路径 —— 它们压根不共享同一个文件。
例如：php-fpm -c /etc/php/8.2/cli/php.ini -y /etc/php/8.2/fpm/php-fpm.conf 启动的 FPM，和终端执行的 /usr/bin/php 完全无关。后者可能连 /usr/bin/php 这个二进制都是软链到 /usr/bin/php8.1，而那个版本又自带一套独立的 php.ini 搜索逻辑。
立即学习“PHP免费学习笔记（深入）”；
- 查 FPM 实际加载的配置：
sudo systemctl status php8.2-fpm看启动命令，或翻php-fpm.conf里的php_admin_value[php_ini]字段 - 查 CLI 实际加载路径：
php -r "echo php_ini_loaded_file();"（若返回 false，说明确实没加载） - 别指望
update-alternatives --config php同时改掉 FPM；它只影响php命令，不影响php-fpm进程或 socket 路径
多个 PHP 版本共存时，如何确认当前 CLI 和 FPM 分别用的是哪个 php.ini
关键不是“怎么统一”，而是“先看清各自用的哪份”。混淆的根源往往在于你以为改了一个地方，其实两个运行时根本没碰同一份文件。
分别执行：
php --ini → 看 CLI 的主配置 + 扫描目录
php -r "echo php_ini_loaded_file();" → 确认 CLI 是否真加载了某份
在 Web 页面中访问 phpinfo() → 找 “Loaded Configuration File” 行，这就是 FPM 当前生效的 php.ini
再查 FPM 进程实际加载的 ini：用 ps aux | grep php-fpm 找出主进程 PID，然后 cat /proc/<pid>/cmdline | tr '\0' '\n'</pid>，看有没有 -c /xxx/php.ini
- 不同版本的 FPM 通常对应不同 socket 路径（如
php7.4-fpm.sockvsphp8.2-fpm.sock），fastcgi_pass指向哪里，就决定了用哪个版本的配置 - 编译安装的 PHP，
php-config --ini-path返回的是构建时设定的默认路径，不一定等于运行时实际加载路径 - 容器环境要额外注意：宿主机
php --ini和容器内php --ini是两套完全隔离的路径体系
为什么改了 /etc/php.ini，CLI 还是不生效
因为绝大多数非包管理器安装的 PHP（尤其是源码编译或第三方仓库如 ondrej/ppa）根本不会把 /etc/php.ini 设为 CLI 默认路径。它更倾向使用二进制同级目录下的 php.ini，比如 /usr/local/bin/php.ini 或 /opt/php/8.2/bin/php.ini。
强行把 /etc/php.ini 软链过去看似省事，但容易引发权限问题（FPM 进程常以 www-data 用户运行，读不了 /etc 下某些被限制的文件）或版本错配（一个 php.ini 同时给 7.4 和 8.2 用，extension_dir 路径必然冲突）。
- 安全做法：每个 PHP 版本维护自己独立的
php.ini，放在该版本的bin/或etc/目录下 - CLI 模式可额外支持
php-cli.ini：若存在，优先于php.ini被读取，适合放仅 CLI 需要的扩展（如pthreads、pcntl） - 永远别依赖“全局一份配置”，PHP 的设计就是允许 CLI/FPM 配置分离的，强行合并反而埋雷
