PHP 8.3配置冲突根源在于php.ini路径、扩展加载、Web服务与CLI环境未对齐；需分别用php --ini和phpinfo()确认实际生效的Loaded Configuration File，检查disable_functions、扩展独立配置文件及FPM/Nginx绑定路径，并严格按顺序重启服务。
PHP 8.3 的配置冲突不是“装不上”，而是php.ini、扩展、Web 服务和 CLI 环境之间没对齐——尤其在多版本共存或从旧版升级时，错一个路径、少一个启用项、多一个禁用函数，就会卡在报错里不动。
确认实际生效的 php.ini 路径，别信 php -v
很多问题表面是“配置不生效”，根源是 PHP 根本没读你改的那个 php.ini。运行 php --ini（CLI 下）或建个 info.php 输出 phpinfo()（Web 下），重点看两行：
-
Loaded Configuration File—— 这才是当前真正加载的 ini 文件路径 -
Scan for additional .ini files in—— 这个目录下的所有 .ini 文件也会被合并加载，容易被忽略
常见坑：/etc/php/8.3/cli/php.ini 和 /etc/php/8.3/fpm/php.ini 是两个独立文件，改了 CLI 的，FPM 还是老配置；CentOS 上 Remi 源安装的 PHP 8.3，ini 路径可能是 /etc/opt/remi/php83/php.ini，不是默认位置。
扩展缺失或禁用函数导致致命错误
PHP 8.3 默认禁用部分危险函数，且扩展加载逻辑更严格。遇到 Fatal error: Call to undefined function chmod() 或 Class "PDO" not found，先查三件事：
立即学习“PHP免费学习笔记（深入）”；
- 运行
php -m看已加载扩展列表，确认pdo、mysqli、openssl等是否在列 - 检查
php.ini中disable_functions行，把chmod、file_get_contents等误删的函数补回来（注意用逗号分隔，末尾别留空格） - 确认扩展配置是否被拆到单独文件：比如 Ubuntu 的
/etc/php/8.3/cli/conf.d/20-pdo.ini是否存在且未被注释
特别注意：PHP 8.3 不再默认启用 mysql 扩展（已彻底废弃），必须用 mysqli 或 PDO；ext-json 已内置，无需额外 extension= 加载。
Web 服务与 CLI 版本不一致
你在终端敲 php -v 显示 8.3，但浏览器打开 phpinfo() 却显示 7.4——这说明 Apache/Nginx 没连上你装的 PHP 8.3。关键动作只有两个：
- 查 FPM 进程：运行
ps aux | grep php-fpm，看启动命令里带的是哪个配置文件（如--fpm-config /etc/php/8.3/fpm/php-fpm.conf） - 核对 Web 服务配置：Nginx 的
fastcgi_pass必须指向 PHP 8.3 的 socket（如unix:/run/php/php8.3-fpm.sock）或端口（如127.0.0.1:9083）；Apache 若用libphp.so，LoadModule 路径必须匹配 8.3 版本（如/usr/lib/apache2/modules/libphp8.3.so）
重启顺序不能错：先 systemctl restart php8.3-fpm（或对应服务名），再 systemctl restart nginx 或 httpd。漏掉 FPM 重启，改了天也白搭。
Composer 项目级 PHP 版本约束失效
即使系统装了 PHP 8.3，composer install 仍可能装错扩展版本，因为 Composer 默认按当前 CLI 版本解析依赖。解决方法不是换系统 PHP，而是锁死项目环境：
- 在
composer.json的config节加："platform": {"php": "8.3.13"}，强制 Composer 按该版本选包 - 若用 Docker，
Dockerfile中明确写FROM php:8.3.13-cli，别用latest或模糊标签 - CI/CD 脚本里加校验：运行
php -r "if (version_compare(PHP_VERSION, '8.3.0', '
最易被忽略的一点：PHP 8.3 引入了只读属性（readonly），但某些旧版 Composer 插件或自定义 autoloaders 在反序列化时会直接写属性，触发 Cannot modify readonly property 错误——这类问题不会出现在 composer install 日志里，而是在运行时崩，得靠 WP_DEBUG_LOG 或 error_log 捕获。
