PHP 8.3 配置检测失败主因是 Composer platform 设置不生效、CLI 与实际 PHP 环境不一致或扩展未真正加载；需确认 composer config platform.php 8.3.0 已写入 composer.json，执行 composer show --platform 验证输出为 8.3.0，并比对 php -v、php --ini 与 Web 环境的配置路径及扩展状态。
PHP 8.3 配置检测失败，通常不是“配错了”，而是检测逻辑被绕过或误判
直接结论：Composer 的 config.platform.php 设置不生效、php -v 和实际 CLI 环境不一致、或扩展未真正加载，这三类原因占了配置检测失败的 90% 以上。别急着改 php.ini，先确认检测对象是不是你认为的那个 PHP。
composer install 报 “requires php >=8.3” 却死活过不了
这不是版本不够，是 Composer 没按你预期的方式读取 PHP 版本。
- 执行
composer config platform.php 8.3.0—— 注意必须是完整三位版本号，8.3或^8.3都无效 - 检查是否写入了
composer.json的config.platform字段，而不是仅存在本地缓存里 - 运行
composer show --platform，确认输出中php行显示的是8.3.0，不是8.2.12或空值 - 如果用的是 WSL 或 Docker，确保
composer命令调用的是宿主机还是容器内的 PHP ——which php和php -v要和composer内部检测的一致
php -v 显示 8.3，但扩展或函数仍报错
说明 CLI 和 Web SAPI（如 Apache/Nginx）用的不是同一个 PHP 实例，或者扩展没启用。
- Web 环境下跑
phpinfo()，重点看Loaded Configuration File和extension_dir路径，和 CLI 下php --ini输出对比是否一致 - 检查
disable_functions是否禁用了关键函数（比如chmod、file_get_contents），WordPress 类项目常因此挂掉 -
fileinfo扩展在 PHP 8.3 下编译失败很常见：不是没装，而是make clean没做、GCC 缺 C99 支持、或内存不足导致make被 OOM Killer 杀掉 - 某些环境（如宝塔）的 PHP 多版本共存时，
phpize和php-config必须严格匹配目标版本路径，例如/www/server/php/83/bin/phpize，不能只敲phpize
本地开发能过，上线就 fail，且错误信息模糊
典型表现是 CI 或生产环境报 “class not found”、“attribute not allowed” 或空白页 —— 很可能不是代码问题，而是 opcache 或 PCRE 版本不兼容。
立即学习“PHP免费学习笔记（深入）”；
- PHP 8.3 默认启用更严格的 PCRE3，旧版正则表达式（尤其路由匹配、插件过滤逻辑）可能静默失效，建议在
php.ini加pcre.jit=0临时验证 - opcache 启用状态下，某些框架（如 Laravel）的自动加载器会因字节码缓存未刷新而漏加载新类，部署后务必执行
php artisan opcache:clear或重启 PHP-FPM - 检查
error_reporting和display_errors：PHP 8.3 对set_error_handler更敏感，若error_reporting(0)，错误处理器根本不会触发，导致“无声失败” - WordPress 插件/主题若声明支持 PHP 8.3，但实际用了
#[Attr]; #[Attr]这种重复 attribute，会在 PHP 8.2 下直接 fatal，别只信声明，要实测
最容易被忽略的点：PHP 8.3 移除了 assert.* 系列 ini 配置项，如果你的项目依赖 assert.exception=1 控制断言行为，升级后这部分逻辑会彻底失效，且无任何 warning —— 它只是安静地退化成老式 assert 行为。
